プラットフォーム・バックエンド開発

境界の明確な少数のサービスに分割し、エッジで動かします。コールドスタート、接続数、リージョン間遅延は設計段階で片づけます。

こんなときに

項目をひとつ増やすのに三つのサービスに手を入れるとき。金曜日に誰も配信したがらないとき。「接続数」という言葉が毎週の定例に出てくるとき。いずれも規模の問題ではなく境界の問題で、境界は引き直せます。

サービスではなくデータから始めます。同じライフサイクルを共有するデータはどれかを先に見極め、その線に沿って境界を引きます。エッジで動かすため、コールドスタートとリージョン間遅延は設計段階で消え、後日の最適化課題になりません。

境界の明確な少数のサービス、文書化されたAPI契約とバージョン方針、本番と同一設定のプレビュー環境、そして可観測性 —— 障害時にどの層で起きたかが見える状態です。

モノリスを十五のマイクロサービスには分割しません。多くのチームに必要な境界は三つか四つで、それ以上は関数呼び出しをネットワーク呼び出しに置き換えただけになり、遅延と新しい障害様式を買うことになります。何本切るべきかは率直にお伝えします。

まず二週間のアーキテクチャ評価から。現在のデータフローと配信手順を読み、「最初に着手すべき三点」を記した文書をお渡しします。多くの場合、その一点目は書き直しではありません。

成果物

2営業日以内に、担当する本人から返信します。