Pular para o conteúdo
thiagoetipadrões

Contatos

apps/architecture/microservices

034 · Arquiteturas de Alto Nível (Macro-Architecture) · ≈ 6 min de estudo

Microsserviços

Cada serviço cobre um contexto de negócio, com banco, deploy e escala próprios, e fala com os outros só por API. A rede passa a falhar no meio da operação, então toda chamada remota tem timeout, retry só no que é transitório, circuit breaker e um fallback com nome. Use quando times, escala ou cadência de deploy já não cabem num monólito modular.

passos
6
arquivos
6
testes
0
tecnologias
6
Infraestrutura realTypeScriptBunElysiaPostgreSQLMariaDBDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Banco digital com três serviços: accounts (saldos, PostgreSQL), fraud (análise de risco, MariaDB — poliglota de propósito) e payments (orquestra a transferência, PostgreSQL). Uma transferência acima de R$ 50.000,00 é bloqueada pela fraude antes de chegar a contas. Quando a fraude cai, a transferência fica em revisão em vez de falhar ou passar sem análise.

Planta

Sequência
10/10
POST /transfers (x-correlation-id)1INSERT transfer pending2POST /analyses (timeout, retry, breaker)3INSERT IGNORE por transfer_id4aprovado, risco5POST /transfers (mesmo transfer_id em todo retry)6idempotencia + FOR UPDATE + debito e credito72018UPDATE completed920110fraude fora do ar ou breaker aberto: 202 pending_review, sem mover dinheiroClientepayments-servicepayments-db PostgreSQLfraud-servicefraud-db MariaDBaccounts-serviceaccounts-db PostgreSQL
10

10 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Serviços autônomos com deploy independente.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

x-correlation-id+3
payments+2
transferId+2
fraud+1
  1. 01

    payments grava a transferência como pending antes de qualquer chamada remota: o ledger sempre sabe onde ela parou

  2. 02

    Cada chamada remota passa por serviceClientCreate: timeout por tentativa, circuit breaker contando cada tentativa (5 chamadas mínimas, 50% de falha abre), retry externo com full jitter só para 502/503/504, timeout e conexão recusada

  3. 03

    Resposta 4xx é decisão do outro serviço: volta sem retry e não conta contra o breaker

  4. 04

    Fraude indisponível ou breaker aberto → fallback nomeado pending_review (202); com o circuito aberto a resposta sai sem tocar a rede

  5. 05

    accounts aplica cada transferId uma vez (account_transfers como chave de idempotência); fraud guarda uma análise por transferId — retry nunca duplica efeito

  6. 06

    O x-correlation-id atravessa os serviços e fica gravado em payments e fraud: uma busca acha a transferência inteira

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Deploy, escala e tecnologia independentes por serviço

  • Falha da fraude degrada para revisão, não derruba pagamentos

  • Banco por serviço: mudança de schema não quebra os outros

  • Correlation id liga logs e registros dos três serviços

Custos

  • Rede no meio de toda operação: latência e falha parcial

  • Transferências em pending_review exigem processo de reconciliação

  • Sem transação entre serviços; idempotência obrigatória em cada um

  • Observabilidade distribuída a montar e operar

apps/architecture/microservices

6 arquivos

src/

  • service_accounts.tsServiço de contas — único escritor de saldos, idempotente por transferId
  • service_fraud.tsServiço de fraude — regra de risco e registro no MariaDB
  • service_payments.tsServiço de pagamentos — orquestração, ledger e fallback
  • client_service.tsChamada remota com timeout, circuit breaker e retry com jitter
  • config_service.tsConfiguração validada por serviço, cada um só com as próprias variáveis

sql/

  • 01_*.sqlschemaUm schema por banco, um banco por serviço

Executar · com Docker

  1. docker compose up -d --wait# sobe PostgreSQL · MariaDB
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real

Cada serviço também sobe como processo próprio: bun run accounts, bun run fraud, bun run payments.

Requisitos
BunDocker
Sobe junto
PostgreSQLMariaDB

Relações

Onde ele se encaixa

Mapa
  1. vem antesAnti-Corruption Layer
  2. Microserviços
  3. próximo passoDatabase per Service
  • Vem antes1
  • Próximo passo1
  • Combina com2
  • Alternativa a3

L4Do monólito aos serviços· estação 5 de 7

← Anti-Corruption LayerDatabase per Service →

Por que se relacionam

Vem antes

Próximo passo

Combina com

Alternativa a

Teste rápido

Qual é o próximo passo depois de Microserviços?

Próximo projeto · Arquiteturas de Alto Nível (Macro-Architecture)Micro-Frontends
Esc

↑ ↓ navegarEnter abrir191 resultados