開發人員在任何軟體專案過程中都會做出數百個微觀和巨集觀決策。有些似乎相對無害，但對下游會有一個很大的影響。幾位Cantina工程師聚在一起，回顧了我們在學習了一些艱苦的經理後需要特別考慮的關鍵點。

1. 利益相關者要求

您作為架構師或系統設計師的首要任務幾乎總是讓所有必要的利益相關者儘快發現需求。

這些需求在專案的初始階段可能是最難獲得的。雖然這種擔憂通常與看似最後一刻的審計和安全要求有關，但請記住上下文規則。

2. 資料讀/寫伸縮平衡

在決定如何構建可伸縮Web應用程式時，關鍵的首要決策是瞭解資料儲存可能需要的讀寫平衡：

• 重型寫：應用程式在擴充套件時會遇到一致性問題，因此應儘早注意模型的寫入完成，資料分發和各種批處理過程。像Twitter和其他人這樣的大量應用程式通常採用流式寫入模式，將訊息傳遞作為支援可伸縮寫入語義的主幹。利用釋出/訂閱（pub / sub）和Google Spanner等併發概念可以提供幫助。（還記得：日誌和資料庫只是彼此的對偶）。
• 繁重讀：此類應用程式可能是隨著它們的增長而最容易擴充套件的。有許多開箱即用的技術可以促進這種模式，包括許多快取機制，高效能鍵值儲存以及MongoDB等流行儲存系統的複製只讀節點。

3.資料一致性

我們中沒有一個人可以逃脫CAP定理!

但只有在出現系統故障，網路故障或其他無法滿足三元組的分割槽（P）元素時才會發揮作用。在這種情況下，應用程式設計人員和架構師必須提出一個棘手而棘手的問題：這個產品可以更好地容忍哪些，一致性失敗或可用性失敗？

• 一致性 - 如果您的應用程式可以同時訪問不同節點的不同狀態，那麼一致性並不是最重要的。當向兩個不同的使用者顯示社交媒體饋送時會出現這種情況，每個使用者的結果略有不同。
• 可用性 -如果追求總是能返回結果，NoSQL運動的資料儲存解決方案或實施BASE語義將是可行的選擇。但是，如果同時為所有同時請求（想想金融交易，銀行，證券交易所）提供正確和相同的答案也很重要，那麼一致性是最重要的，最好不要返回錯誤的結果。這有時會產生昏昏欲睡的結果響應或鎖定狀態，但通常值得花費正確的響應。在這種模式中，具有ACID語義的傳統關聯式資料庫系統通常是應用程式設計的必要初始選擇。

4. 領域/資料模型

在考慮指定系統應該是什麼業務領域時（參見域驅動設計），應該考慮系統的上下文 - 允許通過系統傳遞的非上下文固有的資訊作為文件而不是作為領域模型的一部分。

例如，採用一個系統將天氣資料返回給使用者，但該系統也從另一個第三方服務獲取該資料。

解決方案可能會尋求保持從第三方返回的資料，並將其領域複製為自己的領域。這將迫使架構管理一個更復雜的領域，該領域具有許多可能永遠不會使用的關係，但必須隨著時間的推移而維護。

通過將較小的關聯式資料庫與文件儲存相結合，它還將模糊改善資料訪問效能和簡單性的潛力。

像這樣的問題可以通過埠和介面卡等範例來解決。通過完全理解系統的領域而不包括領域環境不固有的資訊，架構師能夠做出能夠極大地提高設計效能和可維護性的儲存技術決策。

5. 負載的可變性

在災難或公共事件期間接收大量負載峰值的API（例如Facebook）將具有與從空氣質量感測器接收預期的每小時度量標準的要求截然不同的要求。

利用可以有效計量請求的體系結構（佇列，熱表等）可以緩解這些問題中的一些問題。

如果資料一致性不是系統中最重要的問題（如前所述），那麼複製資料系統可以幫助在請求進行負載平衡或智慧路由時保持單一入口點的壓力。

雖然無伺服器計算提供了諸如內建擴充套件等顯著優勢，但它需要更多純函式的無狀態程式碼結構。對於新系統的綠地greenfield實施，這可能沒問題，但遷移遺留系統可能是一個挑戰。