分散システムを扱うと，部分的障害(Partial Failure)のような問題が発生する。この種の問題や他の課題に対して最大限できることは，問題が起きないように願うだけではなく，それらに備えることだ - InfoQとのインタビューでVaughn Vernon氏はこのように説明して，分散システムの経験が浅い開発者に対する現実的なアプローチと実践的アドバイスを書いたJeff Hodges氏のブログ記事を紹介してくれた。
“Implementing Domain-Driven Design”および新刊の“Reactive Messaging Patterns with the Actor Model”を著書に持つVernon氏にとって，Hodges氏の助言で最も素晴らしいのは，部分的可用性(Partial Availability)のための設計を心掛けること，依存性が利用不可能な場合の完全なオペレーション回復のために上限付き指数待機(Capped Exponential Back Off)を使用すること，この２つだ。氏の助言は，障害に見舞われた場合にできる最善の方法であり，Vernon氏の考えを的確に表している。
Hodges氏によると，経験の浅い開発者の多くが，分散コンピューティングで難しいのはレイテンシだと考えている。これに対して氏は，本当の差別化要因は障害，特に部分的障害の発生確率が高いことにあるとして，部分的可用性を確保する方法を見つけるように提言する。例えば，適切に設計された検索システムでは，応答時間の制限によって検索結果の収集をタイムアウトとすることで，システムのレジリエンスを向上している。
堅牢なシステム構築において，Hodges氏の考える基本的なビルドブロックのひとつが，サービスシステムから要求元システムに障害シグナルを返送することで過負荷を防止する，バックプレッシャの機構である。一般的な実装方法には，失敗する可能性のある要求を処理する前にメッセージを破棄する，あるいはエラーを返す，といったものがある。
Hodges氏は，可能な限り多くのサーバ間でコーディネーションを図る方法を推奨していない。代わりに氏が勧めるのは，独立したサーバ間で最小限のコミュニケーションを行う，という方法である。２つのサーバ間で何らかの取り決めをしてしまうと，サーバの実装が難しくなるからだ。
サービスに抽出可能な高レベルのビジネスロジックを探し出すことには，いくつかのメリットが期待できる。まず，カプセル化の促進によってコード修正が簡単になり，デプロイも迅速になる。また，全クライアントに対するデプロイ調整を要する共有ライブラリと比較して，複数クライアントがサービスを使用する場合の調整コストが低いことも，メリットのひとつだと氏は考える。
さらに氏は，インフラストラクチャのロールアウト時に機能フラグ(Fearure Flag)を使用することや，システムの識別スペースを選択する上で考慮すべき要素など，自身のキャリアから学んだ教訓のいくつかを紹介している。