マイクロサービス・アーキテクチャ

1）なぜiGamingのマイクロサービス

変更のスピード：チーム機能（支払い、コンテンツ、リスク、トーナメント）の独立したリリース。
信頼性：1つのサービスの障害により、製品全体がダウンすることはありません（障害制限）。
スケール：「ホット」ドメイン（ウォレット、ロビー、ストリーム）の水平スケール。
コンプライアンス：地域/管轄によるデータの分離。

小さなチーム/ボリューム、DevOpsのプラクティスがなく、テストの自動化が弱い-モジュラーモノリスの方が優れています。

2）ドメイン、国境、チーム（DDD+チームトポロジー）

ドメインの内容：アカウント/プロフィール、CCM/コンプライアンス、決済/ウォレット、ゲームコンテンツ/集計、ボーナス/ミッション、トーナメント、マーケティング/CRM、 レポート/BI。
Bounded Context=Data ModelとLanguage Contract。
コマンド↔フローを変更：1つのコマンド=1つのループ+そのSLO。
BFF （Backend for Frontend）：クライアントの「オーケストレーション」を収集しないように、Web/Mobile/Partner用の個別のファサード。

3）コミュニケーション： 同期対非同期

同期（REST/gRPC）：即時応答が必要な場合（入金限度額の確認）。
Asynchron （Kafka/NATS/SQS）：イベントとバックグラウンドプロセス（キャッシュバックの発生、郵送、評価の更新）。

• クリティカルパス=最小ネットワークホップ。
• クロスドメイン統合-イベントや契約APIを通じて。
• オンラインで「5+同期コールのチェーン」を構築しない→EDA/sagasを使用する。

4）契約およびバージョン管理

契約1： OpenAPI/AsyncAPI+スキーマレジストリ（Avro/JSONスキーマ）。
SemVer+互換性：フィールドを追加するとクライアントが壊れることはありません。
消費者主導の契約（CDC）： CIの自動チェック（回帰）。
拒絶ポリシー：サポートウィンドウ（12-18ヶ月）、古いバージョンのテレメトリー。

5）イベント、サガ、一貫性

Outbox/Transaction Log Tailing： atomic record 「data+event」。

• 支払い/出力のためのオーケストレーション（中央コーディネーター）。
• ボーナス/ミッションの振り付け（イベントへの反応）。
• Idempotence： keys on 'entityId+action+nonce'、 dedup registry storage。
• 一貫性：「外部」-イベントを通じて；「内部」-サービス内のトランザクション。

6）データとストレージ

「自分の店」の原則：各サービスは独自のデータベースを所有しています（スキームの分離）。

• トランザクション/バランスは、厳密な不変量を持つリレーショナル（PostgreSQL）です。
• イベント/ログ-追加のみ（Kafka/Redpanda）。
• キャッシュ/セッション-Redis/KeyDB；leaderboards-Redisソートセット。
• 検索-OpenSearch/Elastic。
• Materialized Read Projections （CQRS）-クイックリスト/レポート。

7）信頼性および安定性

jitter/Retry-budgetでのタイムアウト/再試行は、idempotent操作の場合のみです。
サービス間の遮断器/Outlier-ejection。
隔壁：「騒々しい」上流のための別のプール。
クライアント/ルートごとのレート制限、バックプレッシャー（503+Retry-After）。
キューでのデッドレター+ポイズンメッセージ処理。

8）観察可能性

トレース：OpenTelemetry （shlyuz→servisy→BDによる'trace_id'）。
メトリクス：RPS、 p50/p95/p99、エラー率4xx/5xx、飽和（CPU/mem/queue）、ビジネスメトリクス（TTP、 TtW）。
ログ：構造化JSON、 PII/PAN/IBANマスキング、'trace_id'による相関。

SLO/アラート： route/function（例：'Deposit p95 ≤ 300 ms'、 'success ≥ 98。5%`).

9）安全性とコンプライアンス

ゼロトラスト：mTLS servis↔servis （SPIFFE/SPIRE）、短命の証明書。
AuthN/Z： OAuth2/JWT （aud/scope/exp）、ロールの属性差分。
秘密：KMS/Secrets Manager/Sealed Secrets、キー回転。
GDPR/データのローカリゼーション：地域クラスタ、APIゲートウェイ上のジオフェンシング。
監査：不変ログ（WORM）、管理アクションのトレース。

10）導入とリリース

Containers/K8s： 1つのサービス=1つの展開；リソース/制限；PodDisruptionBudget。
CI/CD： linters、 unit/contract/integテスト、セキュリティスキャン、SBOM。
リリース：カナリア/ブルーグリーン/シャドウ、拡張と契約によるスキーム移行。
Autoscale： CPU+RPS+p95+queue-depthによるHPA；崩壊時に排水する。

11）性能および費用

プロファイリング：p95/99「サービスおよび方法による」、炎グラフ。
キャッシュ：読み取りスルー/書き込みスルー；イベントによってTTL/障害。
データの局所性：ホットデータを計算に近づけます。
FinOps：ダウンロードターゲット60-70％、「暖かいプール」、非アクティブな労働者の自動一時停止。

12）ドメインテンプレート（iGaming）

12.1支払い/ウォレット

サービス：'payment-gw'（ファサード）、'wallet'、 'psp-adapters-'、 'fraud-check'。
ストリーム：'init→reserve→capture/rollback' （saga）。
^Сосииa： 'PaymentInitiated'、 'PaymentAuthorized'、 'PaymentSettled/Failed'。
Idempotency： 'Idempotency-Key'、 'wallet'のデッドアップ。

12.2 CM/コンプライアンス

Path： 'kyc-flow'、 'doc-storage'、 'consolution-check'、 'pep-screening'。
Ссосииa： 'KycSubmitted/Approved/Rejected'、 'RiskScoreUpdated'。
監査とETA：タスクキュー、タイムラインケース、ポストアクション。

12.3ボーナス/ミッション

サービス：'bonus-engine'、 'wallet-bonus'、 'eligibility'。
振付：'BetPlaced→BonusEngine→BonusAssociated→WalletCredited'。
虐待からの保護：idempotent助成金、限界、ルールシミュレータ。

12.4トーナメント/リーダーボード

サービス：'tournament-svc'、 'scoring'、 'leaderboard'。
ストレージ：Redis ZSET+OLAPの定期的な「フラッシュ」。
^^^^「ScoreUpdated」「、TournamentClosed」「、RewardIssued」。

13）契約+イベントの例（簡略化）

OpenAPI（フラグメント）-ウォレット

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI （fragment）-イベント

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14）テスト

ドメインルールの単位/プロパティベース。
CDC （Pact/Assertible）-プロバイダ/消費者契約テスト。
ローカルブローカーとの統合（Testcontainers）。

クリティカルフローE2E （registratsiya→depozit→start igry→vyvod）

カオス/フェイルオーバーテスト：PSPシャットダウン/ブローカードロップ/ゾーン損失。

15）メトリックとSLO（最小）

サービスの可用性：'≥ 99。支払/財布のための9％'。
レイテンシp95：クリティカルパスAPI ≤ 300-500 ms。
エラーの予算：0。1–0.4分の5％、バーンアラート。

キュー： リードタイムイベント（product→consume）、 DLQ ≤ 0。1%.

ビジネス：TTP、 TtW、 FTD成功、KYC-TtV。

16）チェックリスト

サービスデザイン

• ドメイン境界とデータ所有者をクリアします。
• RegistryのOpenAPI/AsyncAPI contracts+スキーマ。
• 定義されたSLO/アラート；metrics/trails/logsがビルドされます。
• タイムアウト/リトレイ/Idempotencyポリシー。
• スキーママイグレーション：expand-and-contract。

リリース前

• 単位/CDC/統合テスト緑。
• カナリアルートとロールバックプラン。
• レート制限/重量ルートが設定されています。
• 秘密/鍵/証明書が発掘されています。
• Fichaフラグとfollbackが用意されています。

17）アンチパターン

データバスとしてのネットワーク：イベントの代わりに深い同期チェーン。
一般的な「神」-すべてのサービスのためのDB。
idempotency→double write-offs/accrualsの欠如。
テレメトリーとキルスイッチのないダークリリース。
隠されたセッション（外部条件の代わりにどこでも粘着性）。
バージョンとCDCのない「コード内」契約。
サービスの代わりにAPIゲートウェイでロジック（ゲートウェイ=薄い）。

18）モノリス移行（ストレングラーフィグ）

1.ファサードゲートウェイとプライマリ回路（支払いなど）を選択します。
2.バイナリロギング（アウトボックス）をモノリスからイベントに削除します。
3.エンドポイントを新しいサービス（ルーティング/カナリアウェイト）に徐々に転送します。
4.モノリスを「コア」に圧縮し、オフにします。

19）スタックとインフラストラクチャ（例）

コミュニケーション：REST/gRPC、 Kafka/NATS；スキーマレジストリ。
リポジトリ：PostgreSQL、 Redis、 OpenSearch、 S3/MinIO；OLAP-ClickHouse/BigQuery。
コンテナ/オーケストレーション：必要に応じてDocker、 Kubernetes （Ingress/Gateway）、 Service Mesh （Istio/Linkerd）。
ゲートウェイ：Envoy/Kong/Traefik/NGINX。
CI/CD： GitHub アクション/GitLab CI+ArgoCD/Flux；Pact/OWASP/ZAP。
観測可能：OpenTelemetry、 Prometheus、 Tempo/Jaeger、 Loki。

20）最終的なチートシート

ドメインとデータの責任による境界の設計。
シンクロン-答えが必要な場合のみ；残りはイベントだ。
契約/スキーム/CDC-回帰保険。
Sagas+outbox+idempotency-信頼性の基礎。
観測可能性とSLOはオプションではなく「、準備ができた」基準です。
canary/blue-greenによるリリース、移行-拡張と契約。
安全/コンプライアンス：mTLS、 JWT、 KMS、地域データ。
まず、モジュラーモノリス、そして進化-スケールとチームの準備ができている場合。