描述58同城的架構演進歷史 在最早時期，因為業務量還不夠，因此整個服務是採用all in one的方式，一台機器做所有的事物，像是DB到web server全部都由一台機器包辦做好，好處是成本低，在業務初期工程師主要工作都環繞在C(create)U(update)R(read)D(delete)的SQL上。這邊作者建議一開始就採用L(linux)A(apache)M(MySQL)P(PHP、python)架構，方便未來做擴充，且不會收錢。及在設計時就導入DAO和ORM設計。
當流量逐漸成長時，採用動靜分離式及讀寫分離式架構，何為動靜分離式架構呢？動態網頁連結web server，靜態檔案如圖片則放到file server做存取，資料存取方面DB成了主要的瓶頸點，業務要求因為讀取需求大於寫入需求，因此改採主從同步，master資料庫為寫入資料庫，slave資料庫為讀取資料庫，以降低資料庫的loading。 但這樣反而造成另一個問題，讀取延遲，寫入的資料庫和讀取的資料庫為了要同步，而發生了延遲性（有多個讀取庫），假若使用者發了一篇文章，他立即去做query發現搜尋不到，使用者以為失敗，反而發更多篇文章，反而增加了額外的loading。另外是站點耦合問題，因為有多樣業務需求，如主頁和帖子的讀取都綁在同一台機器，某項業務出包時容易影響整個業務。
垂直分拆：
因為上述原因，採用了解耦的做法，也就是把每項業務獨立出來，同時在資料庫也以業務做出讀寫劃分，同時解除了讀取延遲和站點耦合。另外也導入了CDN，使使用者在運用資源時可以就近訪問，另外導入M(Model)V(View)C(Control)架構，使開發人員對自己擅長的項目直接開發，增進開發效率。
當資料量越來越大時，便會面臨到成本和效能折衷問題，於是作者提到轉往開源技術架構，另外加入cache於DB前端，並把業務和通用層解耦開來，業務層只需要呼叫相對應抽象層的Function就好，方便開發及維護。
CDN(Content Delivery Network)補充： 就是將自己網站的資料分散到各地，讓使用者可以就近讀取，提高響應速度，缺點是成本會提高，因為是按流量計費，且會有靜態文件更新較慢的問題。
代理及反向代理：
代理： 所謂的代理就是代表用戶訪問server，因為使用者間看到的網頁可能相同，當使用者透過代理伺服器訪問server，代理伺服器可將上個user看的一樣的網頁回傳給user（儲存一份副本在代理伺服器），而不需要再去問server，藉此降低server的loading。
反向代理： 所謂的反向代理即是代表server，客戶端不需要瞭解什麼樣的資源要去跟哪個server要，一率透過反向代理伺服器，藉此亦可降低後端資料庫和server的負載。
另外也多增加了冗余集群，也就是將各個部分做成Cluster管理，使之達到高並發、高性能、高可用性。
接下來便是配置中心、柔性服務和消息總線：
配置中心：紀錄後端現有的服務，當後端要上下現時能透過publish-subscribe方法登記，來了解現有什麼樣的服務。（可見Design Pattern-觀察者模式）
柔性服務：其實就是Auto-Scaling，能觀察現有的客戶量，透過不同的條件限制，來達到服務效能的平衡。
消息總線：消息總線也是一种解耦上下游的技術方法。