Arquitetura de microsserviço

1) Por que os microsserviços em iGaming

Velocidade de alterações: lançamentos independentes de equipes (pagamentos, conteúdo, risco, torneios).
Confiabilidade: falha em um único serviço não varia todo o produto (limite de falha).
Escala: skale horizontal de domínios quentes (carteira, lobby, striptease).
Complacência: segregação de dados por região/jurisdição.

Um pequeno comando/volume, nenhuma prática DevOps, uma fraca automação de testes - então um monólito modular é melhor.

2) Domínios, limites e equipes (DDD + Team Topologies)

Contornos de domínio: Conta/Perfil, CUS/Complaens, Pagamentos/Carteira, Conteúdo de Jogos/Agregação, Bónus/Missões, Torneios, Marketing/CRM, Relatórios/BI.
Bounded Context = contrato de modelo de dados e linguagem.
Fluxo de alterações ↔ comandos: um comando = um traçado + seu SLO.
BFF (Backend for Frontend): fachadas individuais sob a Web/Mobile/Partner para não recolher «orquestração» no cliente.

3) Comunicações: sincronia vs asinharão

Sinchron (REST/gRPC): quando você precisa de uma resposta imediata (verificação de limites de depósito).
Asinhron (Kafka/NATS/SQS): eventos e processos de fundo (pagamento em caixa, distribuição, atualização de classificação).

• Caminho crítico = mínimo de hop de rede.
• Integração entre domínios - através de eventos e APIs contratuais.
• Não construir «cadeias de 5 + chamadas sincronizadas» em linha → usar EDA/saga.

4) Contratos e versionização

Contrato 1: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
SemVer + compatibilidade: adicionar campos não quebra clientes.
Consumer-driven contracts (CDC): carros em CI (contra regravações).
Deprecation policy: janela de suporte (12-18 m), telemetria com versões antigas.

5) Eventos, sagas e consistência

Outbox/Transaction Not Tailing: gravação atômica de dados + evento.

• Orquestração (coordenador central) para pagamentos/conclusões.
• Coreografia (reação a eventos) para bônus/missões.
• Idempotidade: chaves em 'entityId + action + nonte', armazenamento de registro de dedup.
• Consistência: «externa» - através de eventos; «interna» - transações dentro do serviço.

6) Dados e armazenamento

Cada serviço possui o seu BD (isolar os circuitos).

• Transações/balanços - relacionais (PostgreSQL) com invariantes rigorosos.
• Eventos/logs - append-only (Kafka/Redpanda).
• Kesh/sessões - Redis/KeyDB; liderbords - Redis Sorted Sets.
• A busca é OpenSearch/Elastic.
• Projeções de leitura materializadas (CQRS) - listas/relatórios rápidos.

7) Confiabilidade e sustentabilidade

Timeouts/Retry with jitter/Retry-budget apenas para operações idumpotentes.
Circuito-breaker/Outler-ejation entre os serviços.
Bolkhead: balas individuais para upstream «barulhentos».
Rate limits per-client/route, backpressure (503 + Retry-After).
Dead-letter + poison-mensagem handling em filas.

8) Observabilidade (Observabilidade)

Traçado: OpenTelemetry ('trace _ id' através do shlyuz→servisy→BD).
Métricas: RPS, p50/p95/p99, errador rate 4xx/5xx, saturation (CPU/mem/queue), métricas de negócios (TTP, TtW).
Logi: JSON estrutural, camuflagem PII/PAN/IBAN, coralização por 'trace _ id'.
SLO/alertas: para rota/função (por exemplo, 'Deposit p95 ≤ 300 ms', 'sucess ≥ 98. 5%`).

9) Segurança e Complacência

Zero-Trust: mTLS servis↔servis (SPIFFE/SPIRE), certificados de curta duração.
AuthN/Z: OAuth2/JWT (aud/scope/exp), atribuição de papéis.
Segredos: KMS/Secret Management/Sealed Secret, rotação de chaves.
GDPR/localização de dados: clusters regionais, geo-fencing na entrada de API.
Auditoria: Registros imutáveis (WORM), rastreamento de ações admins.

10) Implantação e lançamentos

Contêineres/K8s: um serviço = um deploy; recursos/limites; PodDisruptionBudget.
CI/CD: Linters, unit/contract/testes integ, security scan, SBOM.
Lançamentos: canary/blue-green/shadow, migração de circuitos via expand-and-contract.
Scale automático: HPA por CPU + RPS + p95 + queue-depth; drain ao encurtar.

11) Desempenho e custo

Perfil: p95/99 «por serviços e métodos», gráficos flame.
Cajagem: read-through/write-through; TTL/deficiência por evento.
Data locality: manter dados quentes perto do cálculo.
FinOps: meta de download 60-70%, «warm pools», auto-pausa de workers inativos.

12) Modelos de domínio (iGaming)

12. 1 Pagamentos/Carteira

Serviços: 'payments-gw' (fachada), 'wallet', 'psp-adapters-', 'fraud-check'.
Fluxo: 'init → reserve → capture/rollback' (saga).
События: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.
Idempotidade: 'Idempotency-Key', Dedup em 'wallet'.

12. 2 CUS/Complaens

Сервисы: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.
События: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.
Auditoria e ETA: fila de tarefas, mala de tempo online, pós-acções.

12. 3 Bónus/Missões

Serviços: 'bônus-engine', 'wallet-bónus', 'elisibility'.
Coreografia: « ».
Proteção contra abusos: subsídios idempotent, limites, simulador de regras.

12. 4 Torneios/Liderbords

Serviços: 'turnement-svc', 'scoring', 'liderboard'.
Armazenamento: Redis ZSET + «largada» periódica na OLAP.
События: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13) Exemplo de «contrato + evento» (simplificado)

OpenAPI (fatia) - Wallet

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 (fatia) - evento

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

14) Testes

Unit/Property-based para regras de domínio.
CDC (Pact/Assertible) é um contrato-teste de provedores/consumidores.
Integração com corretores locais (Testcontainers).
E2E flow crítico (registratsiya→depozit→start igry→vyvod).
Chaos/testes Failover: desligamento do PSP/queda do corretor/perda de área.

15) Métricas e SLO (mínimo)

Disponibilidade de serviços: '≥99. 9% 'para pagamento/carteira.
Latency p95: API de caminho crítico ≤ 300-500 ms.
Error budget: 0. 1–0. 5% por trimestre, burn-alerts.
Filas: lead time evento (produce→consume), DLQ ≤ 0. 1%.
Negócios: TTP, TtW, sucess FTD, KYC-TtV.

16) Folhas de cheque

Projetar o serviço

• Limite de domínio claro e dono de dados.
• Contratos OpenAPI/AsyncAPI + esquema em Registry.
• SLO/alertas definidos; métricas/trailers/logs estão incorporados.
• Políticas de temporizações/retrações/idempotação.
• Migração de esquemas: expand-and-contract.

Antes do lançamento

• Unit/CDC/testes de integração são verdes.
• Rota de canário e plano de reversão.
• Rate-limits/rotas de peso configuradas.
• Segredos/chaves/certificados são rodados.
• As bandeiras fichas e os folbacks estão preparados.

17) Anti-pattern

Rede como um pneu de dados: cadeias sincronizadas profundas em vez de eventos.
O'Deus "geral é um BB para todos os serviços.
Falta de idempotidade → débitos duplos/cobranças.
Lançamentos escuros sem telemetria e kill-switch.
Sessão oculta (pegação em todo o lado em vez de um estado externo).
Contratos «em código» sem versão ou CDC.
Lógica na entrada de API em vez de serviços (gateway = fino).

18) Migração com monolítico (Strangler Greg)

1. Selecionar a fachada e o primeiro circuito (por exemplo, pagamentos).
2. Tirar o logo binário (outbox) do monolítico para eventos.
3. Transferir gradualmente os endpoint para um novo serviço (rotação/peso canário).
4. Apertar o monólito para «núcleo» e desligar.

19) Pilha e infraestrutura (exemplo)

Comunicações: REST/gRPC, Kafka/NATS; Schema Registry.
Armazéns: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP — ClickHouse/BigQuery.
Contêineres/orquestra: Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd), se necessário.
Gateway: Envoy/Kong/Traefik/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pact/OWASP/ZAP.
Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Esparguete final

Projete os limites de domínios e a responsabilidade dos dados.
Sinhron - só onde você precisa de uma resposta agora; o resto são eventos.
Contratos/esquemas/CDC - seguro contra regressão.
Sagas + outbox + idempotidade - fundamento da confiabilidade.
Observabilidade e SLO não são uma opção, mas sim um critério «pronto».
Lançamentos via canary/blue-green, migração - expand-and-contract.
Segurança/Complacência: mTLS, JWT, KMS, dados regionais.
Primeiro o monólito modular, depois a evolução - se a escala e o comando estiverem prontos.