通向高可擴展性之路（WhatsApp篇）---- 臉書花了190億買來的WhatsApp的架構

原文連接：http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html

原文寫於2014年2月26日，如下是譯文：

 

在雅虎曾經用C++寫太高性能信息通道的Rick Reed並非高擴展性架構世界中的新手。跟他一塊兒的創業者們都是有豐富可擴展系統經驗的前雅虎人。因此WhatsApp在可擴展性上的實力很是強。並且因爲他們的目標就是讓世界上每一臺智能機（ 幾年內總數將達到50億）都裝上WhatsApp，這一經驗對他們來講相當重要。

在進入正題以前，咱們先來花點時間看看：爲何WhatsApp對於臉書來講值190個億？

做爲一個編程人員，若是你問我WhatsApp是否是值這麼多錢，我確定回答不是！它只是在網絡上傳送一些東西。可是我也是一個認爲咱們不須要博客平臺的人，由於遠程登陸你的服務器，用vi改改index.html文基恩，而後在HTML裏寫你的博文，能有多難呢？後來我認識到作這些事情的代碼有多愚蠢不是關鍵，關鍵是讓用戶喜歡使用你的產品。你不能買到人們的喜好。

那是什麼讓WhatsApp這麼值錢呢？技術？忽視那些說他們能夠在一週內用PHP寫出一個WhatsApp來的人們。這是不可能的。WhatsApp裏面確實用到了一些比較厲害的技術。可是若是臉書想的話，絕對有這個實力來實現一個WhatsApp。

讓咱們來看一看它的一些功能。咱們知道WhatsApp是一個沒有廣告、花招和遊戲，可是有來自全世界的忠實用戶的產品。它在一個短信收費嚴重的世界裏提供免費的短信服務。做爲一個美國人，最讓我驚訝的是有那麼多真實的用戶用WhatsApp來與家人朋友聯繫。當你登錄WhatsApp的時候，極可能發現你認識的不少人已經在使用它了。因爲每一個人都有一個手機，這也減小了有些人不使用社交網絡的問題。WhatsApp積極的在不一樣的手機平臺上發佈，使得每一個你認識的人均可以使用它，並且它just works。「just works」是一個經常使用的短語。它表明全部的含義（共享位置、視頻、音頻、圖片、按住講話、語音短信和照片、讀收據、羣聊、經過WIFI發送信息、以及不論收件人在不在線這一切均可以完成）。它能夠支持各類語音，使用你的手機號碼做爲身份認證，你的手機聯繫人列表就是你的社交圖。這一些都極其簡單。不須要郵件認證、用戶名和密碼、也不須要信用卡號碼。因此它just works。

這些都很厲害，可是也不知190億美金。其餘產品也能夠作到這些功能。

一個緣由多是谷歌也想要買它，由於它是一個威脅，由於多一個用戶能夠賺上99美分。而臉書則是很是急切的須要它，爲了用戶手機中的聯繫人列表，也爲了一些其餘數據（即便WhatsApp什麼也不存）。

這一切都是爲了4億5千萬活躍用戶，而且天天增長一百萬用戶，潛在用戶數量達到10億。臉書須要WhatsApp來得到它的下一個十億用戶。這確定是一部分緣由。何況一個用戶40美金也不是很離譜，尤爲是190億裏的大頭是用股票來支付的。臉書收購Instagram時一個用戶的價格是30美金。一個推特用戶則價值110美金。

Benedict Evans曾經估算過，移動是一個超過一萬億美金的生意。WhatsApp顛覆的是這個生意裏短信那一部分。全球短信系統年收入超過1千億，一天發送200億條短信，而WhatsApp一天發送180億條。現在的大趨勢是從PC端轉到更廣泛的智能機端，這個機遇的規模要比如今臉書所在的市場大得多。

可是臉書保證沒有廣告和干擾，那它能得到什麼呢？

這裏有些頗有趣的移動端商業化的例子。WhatsApp被用來建立一些項目組的羣聊，還有一些風投會用它來進行交易流程的對話。

Instagram在科威特用來賣羊。

微信，一個WhatsApp的競爭者，在一月開通了出租車叫車服務。第一個月就叫了2千1百萬輛次出租車。

電子商務的將來看來會經過一些移動短信app來實現，但這僅僅只侷限於電子商務嗎？

其實不僅有商業會使用WhatsApp來替代之前在電腦或網頁應用。西班牙的警察使用WhatsApp來抓捕罪犯。意大利的人們用它來組織籃球賽。

商業和其餘應用開始向移動端轉移有很充足的理由。每一個人都有手機，並且這些短信應用很強大、免費、用起來成本很低。你再也不須要電腦或者網頁應用來作這些事了。不少功能能夠再一個短信app上實現。

因此短信對谷歌和臉書來講是一個威脅。電腦正在不流行，web也在不流行。短信加移動端構建了繞過傳統渠道的一個完整生態系統。短信取代搜索成了移動端的中心，改變了事物被發現的途徑，也決定了什麼樣的應用能在將來勝出。

臉書想不想要進入這個市場？

隨着轉向移動端，咱們能夠看到臉書的去門戶化。臉書的電腦網頁界面是門戶風格的，提供了全部後端所能提供的功能的入口。它很大、很複雜、很容易出問題。誰真的喜歡臉書的UI？

當臉書像移動端傾斜時，他們也嘗試過門戶風格，但行不通。因此他們採用了一系列更小更專一的不一樣目的的app。移動爲先！你在這麼小的屏幕上只能作有限的事情。在移動端更容易找到一個特定的app，而不是在一個複雜的門戶式應用的重重菜單中找到你想要的東西。

可是臉書走的更遠。他們不只僅提供各類app，他們還提供多個互相競爭的功能相似的app，而這些app可能都不使用相同的後端基礎設施。好比Messenger和WhatsApp，Instagram和臉書的照片app。Paper是另外一個臉書的界面，只提供不多的功能，可是在這些功能上能作的很好。

康威定律在這裏也成立。它的大意是「設計系統的大型機構會受到自身限制而作出和自身的通訊構架類似的設計」。有一個大塊頭的後端基礎架構，咱們就會有一個城堡同樣的前端門戶設計。轉向移動端把大公司從這種思路中解放了出來。若是應用能夠只提供一部分臉書基礎架構的功能，那應用就能夠徹底不依賴與臉書的基礎架構。若是它們不須要臉書的基礎架構，那它們也不須要有臉書來建立。那這個時候臉書仍是臉書嗎？

臉書的CEO Mark Zuckerberg有本身的理解。在移動端世界大會上他說臉書收購WhatsApp是與Internet.org的願景高度相關的：

咱們的宗旨是發展一系列免費的基礎互聯網服務 -- 「一個互聯網的911」。這些服務可使像臉書同樣的社交網絡服務、一個短信服務、搜索、或者像天氣一類的服務。 向用戶提供這些免費服務就像是一種容易上癮的藥  -- 可以承擔的起數據服務和手機的用戶就不會想要花錢來得到這些服務。這會使得他們以爲本身很重要，從而花錢購買其它相似的服務。 -- 或者咱們但願如此。

這是一個長期的目標，須要有巨大的值錢的股票才能玩得起。

那咱們有結論了嗎？不見得。這畢竟是一大筆錢，而直接的好處卻不是很明顯，儘管長期目標的解釋有必定的道理。咱們仍然實在移動的早期。沒人知道將來是什麼樣子的，因此爲了讓將來不會像過去那樣是須要付出代價的。臉書正在這麼作。

這個話題就到此爲止了。讓咱們來看看32個工程師是怎麼支持4億5千萬活躍用戶的。

 

信息來源：

預警：咱們並不知道不少關於WhatsApp的總體架構。只有從不少來源獲得的一星半點信息。Rick Reed的演講是關於如何用Erlang來讓每臺服務器能夠支持2百萬鏈接的優化過程，很是有趣，可是不是一個關於總體架構的演講。咱們的來源有：

• Rick Reed 2012 的演講 Scaling to Millions of Simultaneous Connections 
• Rick Reed 的Erlang Factory interview
• An interview with Eugene Fooksmam from WhatsApp
• DLD14 - What's up WhatsApp? (Jan Koum, David Rowan)
• yowsup是一個WhatsApp的API的開源版。由於DMCA的關閉，這個代碼庫已經沒法下載了。可是他們確實記錄了一些WhatsApp的內部工做。好比，全部事情都會搞多樣化。
• 一些在相關文獻中提到的來源。

 

數據：

這些數據大部分來自現有系統，而不是演講時的那個系統。那個演講會包括更多的數據存儲的改動、消息、大集羣和更多的BEAM/OTP的補丁。

• 4億5千萬活躍用戶，比任何公司更快的達到了這一數字
• 32個工程師，每一個人支持1千4百萬活躍用戶
• 七個平臺上天天500億條信息（收+發）
• 天天超過1百萬新增用戶
• 廣告投入爲0
• Sequoia Capital投了6千萬；回報是34億
• 臉書35%的現金用在了這單交易中
• 數百個節點
• 大於8000個核
• 數百TB的RAM
• 每秒超過7千萬條Erlang消息
• 2011年WhatsApp在單一服務器上有1百萬tcp會話鏈接，還能有內存和CPU的剩餘；在2012年能夠有2百萬tcp鏈接；2013年WhatsApp在推特上公告，12月31號產生了一個新紀錄：收了70億短信+發了110億短信=總的一天180億條短信！2013年快樂！！！

平臺：

後端：

• Erlang
• FreeBSD
• Yaws， lighttpd
• PHP
• BEAM的特製補丁（BEAM就像JAVA的JVM，可是是Erlang的）
• 特製XMPP
• 可能在Softlayer中運行

前端：

• 七個客戶端平臺：iPhone、安卓、黑莓、諾基亞塞班S60、諾基亞S40、Windows Phone、？
• SQLite

硬件：

標準的涉及用戶的服務器：

• 兩個Westmere Hex-core（24個邏輯CPU）
• 100GB RAM， SSD；
• 雙NIC（一個公有鏈接用戶的網絡，一個私有與後端相連的網絡）

產品：

• 關注消息。鏈接全球的人們，無論他們在哪裏，也不須要他們花不少錢。創立人Jan Koum還記得在1992年時要和全世界不一樣地方的家人們保持聯繫有多難。
• 私密性。這與Jan Koum在烏克蘭長大有關，那裏沒什麼東西是保密的。消息不會被存在服務器上；聊天記錄也不被保存；目標是對用戶瞭解的越少越好；不知道用戶的姓名和性別；聊天記錄只在用戶的手機上。

概述：

1. WhatsApp的服務器幾乎徹底基於Erlang：

• 後端短息路由系統是由Erlang實現的
• 一個巨大的成就是隻有不多的服務器就管理了這麼多的活躍用戶。WhatsApp團隊一致認爲這很大程度上市Erlang的功勞。
• 有趣的是2009年時Facebook Chat也是用Erlang寫的，可是後來他們放棄了，由於很難找到合適的程序員。

2. WhatsApp的服務器從ejabberd啓動：

• Ejabberd是一個著名的開源Jabber 服務器的Erlang版
• 一開始選它是由於它是開源的，代碼通過不少程序員審覈，容易入手，而且從長遠來看Erlang對大型通訊系統十分合適
• 接下來的幾年花在了重寫和改變ejabberd的部分代碼上，包括從XMPP換到一個內部開發的協議、修改代碼結構、從新設計一些核心組件、以及對Erlang VM作出了許多重要改變來提升服務器性能

3. 一天處理5百億條消息的重點在於有一個可靠、可用的系統。賺錢是之後的事情，還有很遠的路要走。

4. 一個主要的衡量一個系統是否健康的標準就是消息隊列的長度。一個服務器上全部進程的消息隊列長度都被實時監控着，一旦超過某一個預設的值就會發出警報。一旦一個或多個進程發出警報，那就說明這是下一個須要解決的瓶頸。

5. 發送多媒體消息時，圖片、音頻或視頻會被上傳到一個HTTP服務器，而後這個內容的鏈接以及一個用Base64編碼的預顯示內容（若是有的話）會被髮送出去。

6. 有些代碼天天都會被改變。常常是一天幾回，雖然一般會避開高峯時刻。Erlang有助於積極地上線修復和新的功能。熱加載意味着更新能夠在不用重啓或者轉移負荷的狀況下啓用。錯誤常常很快就能經過熱加載來糾正。系統設計地比較鬆耦合，使得遞增地推出新的東西變得很容易的。

7. WhatsApp用了什麼協議？SSL通訊管道通向WhatsApp的服務器池。全部的消息都在服務器的隊列上，直到客戶端下一次鏈接而後取走消息。成功獲取一條消息的狀態會被送回WhatsApp的服務器，而後被轉發個發送消息的那我的（他會看到這條消息旁邊出現了一個勾）。一旦客戶端接收的這些消息，它們就會在服務器的內存中被刪除。

8. WhatsApp內部的註冊過程是怎麼實現的？WhatsApp曾經基於手機的IMEI號碼建立一個用戶名密碼。可是最近修改了這一機制。WhatsApp的客戶端如今經過一個通用API發送一個獨特的5位PIN。WhatsApp而後會發送一條短信到這個手機號碼（這意味着WhatsApp的用戶不在須要使用同一部手機了）。根據這個PIN，客戶端會請求一個獨特的鍵。這個鍵就被當作將來全部請求的密碼。（這個永久的鍵被存在手機中。）這也意味着註冊一臺新的設備會使得老設備上的鍵失效。

9. 安卓平臺上使用了谷歌推送服務。

10. 安卓平臺上有更多的用戶。安卓開發也更友好一些。開發者能夠開發一個功能的初始版，而後一個晚上就能夠把它推送到億萬用戶的機器上。若是有什麼問題就能夠立刻修復。在iOS上就不行。

每臺服務器超過2百萬鏈接：

1. 巨大的用戶增加，這是一個幸福的煩惱，但這也意味着要花不少錢買更多的設備以及增長管理這些設備的複雜程度。

2. 須要爲負荷的激增作好計劃。例如西班牙或者墨西哥有足球比賽或者地震的時候。這些一般在原本就是高峯的時候發生，因此須要有足夠的空閒帶寬來處理高峯+激增。一次最近的足球比賽在本來的高峯期基礎上又產生了35%的發送增量。

3. 本來的服務器能夠同時處理200個鏈接：

• 能夠推斷須要不少的服務器來知足增加須要
• 服務器在忽然到來的負荷面前很脆弱。網絡故障和其餘問題會出現。須要解耦各個部件使它們在高峯期不那麼脆弱
• 目標是一臺服務器1百萬個鏈接。這是在他們能夠實現20萬鏈接時定下的極有野心的目標。還要讓服務器有多餘的容量來處理世界性活動、硬件故障以及其它各類問題意味着要有足夠的彈性來處理高負荷和故障。

用來增長可擴展性的工具和技術：

1. 系統主動彙報工具（wsar）：

• 記錄一個系統的各類數據，包括OS數據、硬件數據、BEAM數據。它被設計成能夠很容易從其餘系統插入測量數據的模式，例如虛擬內存、跟蹤CPU使用率、整體使用率、用戶時間、系統時間、中斷時間、上下文轉換、系統調用、陷阱、收/發包、全部進程隊列中的消息總數、繁忙端口事件、通信負荷率、輸入輸出比特數、調度數據、垃圾回收數據、收集到的文字、等等
• 原來每分鐘跑一次。隨着系統性能提高，須要每秒運行一次，否則有些事件在一分鐘的精確度上是發現不了的。如今數據很是精確，能夠看到全部部件是如何工做的。

2. CPU中的硬件性能計數器（pmcstat）：

• 能夠看到CPU在哪裏花了多少比例的時間。能夠看到多少時間被用在了仿真器的循環上。在他們的例子上，只有16%的時間用來執行仿真器中的代碼上了。也就是說即便他們一點也不運行Erlang代碼，也就只能節省16%的時間。意味着他們應該在其餘地方想辦法提高系統的性能。

3. dtrace、內核鎖計數、fprof：

• Dtrace主要用於debug，而不是性能
• 在FreeBSD上給BEAM打補丁來得到CPU時間戳
• 寫了一些腳本，把全部進程的信息彙總到一個地方來顯示時間都花在了哪些步驟上
• 最大的收穫是在編譯仿真器的時候開啓鎖計數

4. 一些問題：

• 早期看到不少時間或在垃圾回收上，這個已經下降了
• 看到一些網絡堆棧上的問題，也被解決了
• 最大的問題在於仿真器中的鎖競爭，能夠從鎖計數的輸出中發現

5. 測量：

• 合成負荷，那些從你本身的測試腳本中產生的負荷，在用戶規模很是大的時候，對於用戶會接觸到的系統的測試做用頗有限：
  • 對於簡單的接口頗有用，好比一個用戶表格，儘快的產生插入和讀取
  • 若是要測試一臺服務器支持1百萬個鏈接，須要讓30臺機器打開足夠的IP端口，才能產生足夠的鏈接。對於2百萬鏈接就須要60臺機器。這麼大的規模就很難測試。
  • 產品線上能夠看到的負荷的類型也很難產生。能夠假設一個正常的負荷是什麼類型的，可是其實由於社交活動、世界性的活動、在不一樣的平臺上用戶的行爲不一樣、不一樣的國家，這些因素都會致使負荷的類型變化很大
• Tee‘d負荷：
  • 把正常的產品線上的負荷複製一部分到一個分離的系統
  • 有效地把反作用限制住了。咱們不但願複製負荷的同時改變一個用戶的永久狀態或者致使發送重複的信息給用戶
  • Erlang支持熱加載，因此在滿負荷下，若是有一個新想法，能夠在程序運行的同時編譯並加載這個變化，而且立刻看到這個變化時變好了仍是變壞了
  • 增長一些旋鈕來動態調節產品線負荷，並觀察性能會如何收到影響。能夠一邊輸出CPU使用率、VM使用率、監聽隊列溢出等數據，一邊調節旋鈕看整個系統如何反應
• 真實產品線負荷：
  • 終極測試，同時輸入和輸出。
  • 在DNS中重複寫入一個服務器的信息，因此它會獲得兩倍或三倍於正常數值的負荷。製造一些TTL的問題來模擬客戶端不適用DNS規定的TTL或者出現了延時，因此不能很快地針對負荷過載進行處理。
  • IPFW。把負載從一臺服務器轉移到另外一臺，這樣可使一臺機器正好有那麼多客戶端的鏈接。可是一個bug可能引發內核恐慌，因此不是很行的通。

6. 結果：

• 從一臺服務器有20萬個併發鏈接開始
• 第一個瓶頸是42萬5千個鏈接。系統一直處於競爭狀態，真正的活沒人幹了。測量調度器數值來觀察多少有用的工做正在執行、或睡眠、或循環。發如今負荷下，它一直試圖獲取睡眠鎖，因此整個系統CPU使用率只有35%-45%，可是調度器有98%的使用率
• 第一輪修復就達到了1百萬的鏈接：
  • VM利用率在76%。CPU在73%。BEAM仿真器的利用率爲45%，與用戶進程比例很接近。這是一個好事，由於仿真器就是以用戶權限運行的。
  • 一般CPU利用率並非一個很好地衡量一個系統有多忙的數據，由於調度器也是用CPU
• 一個月後，趕上了2百萬鏈接的瓶頸
  • BEAM的利用率在80%，很接近FreeBSD開始換頁的極限。CPU也差很少。調度器開始競爭狀態，不過總的仍是運行的比較穩定。
• 彷佛不太須要繼續優化Erlang代碼了：
  • 原來一個鏈接有兩個Erlang進程，把數量降到了1個
  • 對計時器作了一樣的事情
• 最高峯時每臺服務器有2百80萬鏈接：
  • 每秒57萬1千個包，超過20萬條消息
  • 作了一些內存優化，把VM負荷降到了70%
• 試過3百萬鏈接，可是失敗了
  • 當系統出問題時，發現了很長的消息隊列，無論是一個消息隊列仍是消息隊列的總和
  • 把每一個進程的消息隊列數據加到了BEAM的管理界面中，顯示多少消息被接收和發送，以多快的速度
  • 每十秒鐘採樣一次，能夠看到一個進程的消息隊列中有60萬消息，每秒處理4萬條消息須要15秒。算上期間接收的新消息，總的消化時間須要41秒。

7. 發現：

• Erlang + BEAM + 他們的修復 -- 擁有很牛逼的SMP可擴展性。近乎線性的擴展性。很是厲害。一個24通道的機器運行這套系統處理產品線的負荷會佔用85%的CPU，它能夠一直運行下去而不出什麼問題：
  • 這是對Erlang編程模型的一個證實
  • 一個服務器運行的時間越長，就會有越多長時間的鏈接，這些鏈接幾乎沒有負荷，因此它就能夠接受更多的鏈接
• 競爭是最大的問題：
  • 他們的Erlang代碼裏有一些針對BEAM競爭問題的修復
  • 一些BEAM的補丁
  • 分割負載，這樣每一個CPU的負載就小了
  • 當前時間鎖。每次一條消息離開一個端口的時候它會更新當前時間。這是一個全部調度器共享的鎖，意味着全部的CPU都會用到這個鎖。
  • 優化計時器的使用。不使用bif計時器。
  • 檢查IO時間表會致使指數增加。建立的VM有一個哈希表，會被重複分配。使用幾何分配這個表能夠優化性能。
  • 增長一個文件來記錄全部你已經打開的端口能夠減小端口競爭
  • Mseg分配本來是一個全部分配器之間的競爭。把它的競爭範圍所減到每一個調度器的範圍。
  • 在接受一個鏈接的時候有不少端口之間的交互。修改一些選項能夠減小昂貴的端口間交換。
  • 當消息隊列變大時，垃圾回收會使整個系統不穩定。因此暫停垃圾回收知道信息隊列沒有那麼大時才進行。
• 避免一些常犯的錯誤：
  • 一個從FreeBSD 9引入FreeBSD 8的TSE時間計數器。這是一個更快的讀計數器。能夠更快的拿到當前時間，比查詢一個芯片要快。
  • 從FreeBSD 9引入igp網絡驅動，以解決多個網卡上隊列查詢的問題
  • 增長文件和網絡管道的數量
  • pmcstat顯示不少時間花在網絡堆棧查詢PCB上。因此擴大哈希表的容量能夠加快查詢速度
• BEAM補丁：
  • 以前提到的工具補丁。增長調度器儀表盤來獲取使用率信息、消息隊列的數據、睡眠次數、發送速率、消息計數、等等。這些能夠經過Erlang代碼和procinfo來作，可是在1百萬鏈接時太慢了
  • 數據收集是頗有效的，由於它們能夠運行在產品線中
  • 數據有三個不一樣時間間隔：一、十、100秒。這樣能夠觀察到不一樣的問題。
  • 讓鎖計數能夠在更大的異步線程中工做
  • 增長debug選項來debug鎖計數器
• 調試：
  • 設置一個較低的調度器醒來閾值，不然調度器會一直睡眠
  • 優先mseg分配器，而不是malloc
  • 每一個調度器的每一個實例都有一個分配器
  • 把頁的值設的比較大。讓FreeBSD使用超級頁。減小TLB找不到的機率，提高同一個CPU的吞吐量
  • 把BEAM運行在實時優先級上，這樣其餘例如cron的任務就不會打擾調度，能夠防止致使重要用戶負荷堆積的小問題
  • 下降空循環次數，因此調度器不會空循環
• Mnesia
  • 優先os：timestamp，而不是erlang：now
  • 不要使用交易，可是遠程複製會堆積起來。並行複製表格能夠增長吞吐量
• 有不少改變都沒有在這裏列舉出來

教訓：

• 優化是一個又黑暗又骯髒的活，只適合巨怪和工程師。當Rick作出這些改變使服務器能夠接受2百萬鏈接時，有不少工做要作：寫工具、運行測試、引入代碼、在技術堆棧的每一層加入儀表盤、調試系統、觀察數據、與很底層的細節打交道以及試圖理解全部的事情。這就是去除瓶頸，把性能和可擴展性推到極致索要付出的代價。
• 獲取你須要的數據。寫工具。給工具打補丁。添加旋鈕。Ken不停的修改這個系統來獲取他們須要的數據，不停地寫工具和腳原本管理他們的數據，優化這個系統。作任何須要的事情。
• 測量。去除瓶頸。測試。重複這一過程。這是你該作的。
• Erlang太棒了！Erlang不斷證實它可用來寫一個多功能的、可靠地、高性能的平臺的能力。儘管我我的對這個說法有必定的保留，畢竟它還須要這麼多的調試和打補丁。
• 解決有問題的代碼就能夠獲利。
• 如今價值和員工數量正式沒有關係了。如今有不少可利用的工具。一個先進的全球通訊基礎設施使WhatsApp這樣的應用成爲可能。若是WhatsApp須要先創建一個網絡或造一個手機，這就不可能發生。強大又便宜的硬件和開源軟件固然又是一大利器。這些正確的產品在正確的時間正確的地點出如今了正確的購買者面前。
• 關注用戶很重要。WhatsApp致力於成爲一個簡單的消息應用，而不是一個遊戲網絡，或者一個廣告網絡，或者一個消失的照片網絡。這對他們很重要。這讓他們不打廣告、在增長新功能的時候保持應用的簡單、以及在任何手機上實現「just works」這一理念。
• 因爲簡單而致使的限制是能夠接受的。你的身份與手機號碼綁定。因此若是你換了手機號碼，你的身份也沒了。這個不像電腦。可是這讓整個系統在設計上簡單了不少。
• 年齡什麼也不是。若是2009年的時候WhatsApp的創始人Brian Acton是由於年齡歧視而沒有得到推特和臉書工做的話，那真是一種諷刺。
• 開始要簡單，而後再變化。一開始服務器端是基於ejabberd。它後來被重寫了，可是那只是Erlang方向的第一步。後來Erlang的可擴展性、可靠性和可維護性獲得了愈來愈多的應用。
• 保持不多的服務器。一直保持儘量少的服務器數量，同時又保證足夠的冗餘來處理一些活動引發的短時間陡升的消息量。分析和優化直到它們不起做用，而後部署更多的硬件。
• 有意提供冗餘的硬件。這樣能夠保證用戶在節日期間有不間斷的服務，而僱員也能夠享受假日，不用把整個假日用來修復過載問題。
• 當你收錢時增加就會放緩。當WhatsApp免費時，增加超級快，一天有1萬個下載。當收費以後就降低到1千一天。在年末，當有了圖片消息以後，他們先是收一個一次性的下載費，後來改爲年費。
• 創意來自最奇怪的地方。常常忘記Skype帳號用戶名和密碼的經歷致使了作一個「just work」的應用的熱情。