ベトナム有数のeウォレットのウォレットコアと周辺システムの背後にあるアーキテクチャの判断 — そして、私たちなら何を変えるか。
「マイクロサービス」はしばしば、すべてをバラバラに分割することだと読まれます。実際には、価値はサービスの数ではなく、正しい境界を引くこと — 組織図の周りではなく、ビジネスケイパビリティの周りに引くことにあります。
国民規模のeウォレットのウォレットコアと周辺システムを構築する中で、私たちは一貫性・セキュリティ・スケーラビリティに関する厳しい要件のもと、数百万件のトランザクションを処理しました。本番環境との接触を生き延びた教訓をいくつかご紹介します。
1. サービスの境界はビジネスに従う
サービスは、完結したビジネスケイパビリティとそのデータを所有すべきです。もし2つのサービスが更新のたびに一緒に変更しなければならないなら、それは境界が誤っている兆候です — それらは1つであるべきです。
2. 同期である必要がないものにはイベント駆動を
- お金の移動は強い一貫性を必要とします — 冪等性を持たせ、同期的に扱います。
- 通知、照合、分析 — イベントを通じて押し出し、非同期で処理して、メインフローをブロックしないようにします。
- 各イベントは起きた事実であって命令ではありません — プロデューサーに触れることなく、新しいコンシューマーを追加できます。
3. 明確な契約を伴うAPIファースト
コーディングの前にAPI契約を定義することで、チームは並行して作業でき、最後の苦しい統合を減らせます。あらゆる契約の変更はバージョン管理され、既存のコンシューマーを決して壊しません。
マイクロサービスはスピードをただで与えてはくれません — コードの複雑さを運用の複雑さと引き換えにするのです。そのコストは、規模が本当にそれを要求するときにのみ支払いましょう。
私たちなら何を変えるか
より少ないサービスから始めましょう。よくモジュール化されたモノリスを、スケーリングの圧力が現れるにつれて徐々に分割する方が、早すぎる分割と後からの統合よりも、ほぼ常に安上がりです。可観測性のインフラは、10番目のサービスの後ではなく、2番目のサービスの前に存在すべきです。