Pular para o conteúdo

apps/architecture/monolithic

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

Arquitetura Monolítica

Todos os componentes — contas, pagamentos, fraude e notificações — rodam num processo só, sobre um banco só. Uma transferência é uma transação ACID que atravessa todos eles, sem rede no meio. É o ponto de partida certo para a maioria dos sistemas; o projeto também mostra como medir o monólito antes de decidir o que extrair dele.

passos
6
arquivos
6
testes
0
tecnologias
5
Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker
Baixar cartão

Cenário

Banco digital no início: um único serviço recebe a transferência, consulta a regra de fraude (bloqueio acima de R$ 50.000,00), move os saldos, grava a transferência e enfileira as duas notificações — tudo numa transação. Com o crescimento, o time precisa decidir por onde começar a quebrar o sistema, e decide por evidência.

Planta

Fluxo
8/8
Um processo Bun, um deployCliente HTTPapp_monolithElysiapaymentsfraudaccountsnotificationsPostgreSQLum schema, uma transacaoimport diretoimport diretoUPDATE accounts direto
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Uma base, um deploy, um banco.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

  1. 01

    payments chama fraud por função: recusa antes de abrir qualquer transação

  2. 02

    Numa única transação, payments trava as contas em ordem de id, atualiza a tabela accounts diretamente, grava transfers e chama notifications com o mesmo client

  3. 03

    Falha em qualquer escrita desfaz tudo — débito, transferência e notificações — sem saga nem compensação

  4. 04

    O preço aparece no códigopayments escreve a tabela de outro componente e importa os internos dos vizinhos

  5. 05

    analysis/decomposition.ts inventaria os componentes (pastas folha), conta statements com o compilador TypeScript, mede acoplamento de saída e de entrada e acha tabelas com mais de um escritor

  6. 06

    A ordem de extração sai da evidência: periferia sem acoplamento de saída primeiro (notifications, fraud), accounts depois de a tabela ter um só escritor, o núcleo payments por último

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Transação ACID entre componentes, sem saga

  • Chamada em memória, depuração num processo só

  • Um artefato, um deploy, um banco

  • Ponto de partida simples e barato

Custos

  • Escalar pagamentos escala o sistema inteiro

  • Falha num componente derruba todos

  • Componentes escrevem tabelas uns dos outros sem nada impedir

  • Sem medição, a quebra posterior vira chute — e o núcleo é extraído cedo demais

apps/architecture/monolithic

6 arquivos

src/payments/

  • service_payment.tsTransferência numa transação que cruza todos os componentes

src/accounts/

  • service_account.tsAbertura e consulta de contas

src/fraud/

  • service_fraud.tsRegra de risco

src/notifications/

  • service_notification.tsMensagem ao cliente na transação de quem chama

src/

  • app_monolith.tsO deploy único: HTTP e pool

src/analysis/

  • decomposition.tsRelatório de decomposição: tamanho, acoplamento, escritores compartilhados, ordem de extração

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  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 decomposition
  6. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Monolítico?

Próximo projeto · Arquiteturas de Alto Nível (Macro-Architecture)Monólito Modular
Esc

↑ ↓ navegarEnter abrir191 resultados