Arquitetura de software, decisões e trade-offs

Bloco F · Semana 12 (abre o bloco) Tempo estimado: 22 min de leitura + ~3h de prática (mapear arquitetura Team Studio) Output prático: você participa de discussão arquitetural com CTO/arquiteto sem virar espectador

TL;DR

Bloco F é o mais comercial - tradução do que aprendemos nos Blocos A-E em conversas que fecham negócio. Começa aqui na Semana 12 com o tema que mais aparece em reunião com CTO/arquiteto de cliente: decisões arquiteturais e seus trade-offs.

Você vai entender:

O dilema monolito vs microserviços sem ideologia - quando cada um vence
Modular monolith - o padrão de 2026 que pega o melhor dos dois mundos
CAP theorem revisitado - aplicado em decisões concretas
Event-driven architecture - quando faz sentido e quando piora tudo
6 padrões arquiteturais comuns - API Gateway, BFF, Sidecar, Saga, Circuit Breaker, Bulkhead
6 anti-padrões reais que aparecem em propostas de arquiteto júnior
ADR (Architecture Decision Records) - documentar decisões pra você ou pra cliente
Arquitetura Team Studio hoje - caso concreto com mapa real
5 perguntas que destravam reunião arquitetural
Exercício prático - avaliar proposta de arquiteto de cliente

Como chegamos aqui (recap Bloco E)

Bloco E te deu segurança e compliance: Zero Trust, IAM, OWASP, threat modeling, LGPD/GDPR avançado, SOC 2, ISO 27001, VSR. Você consegue passar por auditoria.

Mas tem outro tipo de cliente sofisticado: o que quer entender como Team Studio se encaixa na arquitetura dele. Esse cliente vai perguntar coisas tipo:

"Vocês são monolito ou microserviços?"
"Como vocês lidam com eventos assíncronos?"
"Por que escolheram Supabase em vez de DynamoDB?"
"Têm Circuit Breaker entre Team Studio e nossa API?"
"Como vocês evitam distributed monolith?"

Sem repertório arquitetural, você fica em silêncio ou improvisa - e improvisar com arquiteto é morte rápida.

Essa semana abre o Bloco F (Arquitetura e Comercial).

1. O dilema fundacional: monolito vs microserviços

Talvez a discussão mais polarizada da engenharia de software dos últimos 15 anos. Em 2026 a poeira já assentou bastante, mas a maioria dos profissionais ainda fala como em 2018.

O mito do "microserviços = moderno"

Por volta de 2014-2018, o discurso era unanime: "microserviços é o futuro, monolito é legado". Netflix, Uber, Spotify exibiam arquiteturas de centenas de microserviços. Conferências falavam só disso. Livros vendiam aos montes.

Em 2020-2025 começou o backlash sério:

Amazon Prime Video (set/2023) publicou artigo admitindo que migraram de microserviços de volta pra monolito num serviço crítico, reduzindo custo em 90%.
Shopify (jul/2023) confirmou que continuam num modular monolith Ruby on Rails que processa Black Friday inteira sem problemas.
Basecamp/37signals (jan/2024) virou voz pública contra microserviços prematuros (DHH defendendo "majestic monolith").

Em 2026, o consenso é: microserviços resolvem problema de organização (Conway's Law), não problema de software. Não é arquitetura moderna; é arquitetura adequada quando você tem organização específica.

Conway's Law e seu corolário

Melvin Conway, 1967: "Sistemas refletem a estrutura de comunicação das organizações que os produzem."

Corolário: arquitetura de microserviços faz sentido quando você tem 8+ times trabalhando em paralelo, cada um responsável por uma fatia do produto. Antes disso, você está forçando microserviços em estrutura de monolito - o que dá distributed monolith (vamos ver).

Quando monolito ganha (= até quase sempre)

Monolito vence quando: - Time pequeno (1-15 desenvolvedores) - coordenação interna é mais fácil que entre serviços - Produto evolui rápido - refactor numa codebase só é exponencialmente mais fácil - Latência importa - chamada de função é nanosegundos, chamada de rede é milissegundos - Custo operacional importa - 1 deploy em vez de 30, 1 banco em vez de 12, 1 dashboard em vez de N - Debugging tem que ser rápido - stack trace local em vez de distributed tracing - Você não tem time SRE dedicado - microserviços exigem operação séria

Cenário típico: 90% das startups e PMEs deveriam estar em monolito. A maioria escolhe microserviços porque o tech lead leu blog post.

Quando microserviços fazem sentido (mais raro do que se imagina)

Microserviços vencem quando: - Time grande (50+ desenvolvedores divididos em 8+ squads) - Escala absurda de tráfego onde subset do sistema precisa escalar independente do resto - Requisitos de stack heterogênea (parte em Python pra ML, parte em Go pra latência baixa, parte em Java pra integração legada) - Disponibilidade exige isolamento total (uma falha não pode derrubar outras partes) - Frequência de deploy heterogênea (parte muda diariamente, parte muda anualmente) - Compliance exige isolamento estrito (PCI scope reduzido, por exemplo)

Exemplo legítimo: Netflix com 200+ microserviços faz sentido porque tem 4.000+ engenheiros divididos em 60+ squads e tráfego de 200M+ usuários simultâneos. Replicar Netflix sem essas condições é teatro arquitetural.

Distributed Monolith: o pior dos dois mundos

Quando empresa tenta microserviços sem ter organização pra isso, sai:

Serviços com acoplamento alto (mudar um exige mudar 3 outros)
Banco compartilhado entre microserviços (acabou com isolamento)
Deploy coordenado (todos os serviços têm que subir juntos)
Latência absurda (request faz 8 hops antes de responder)
Falhas em cascata (um serviço fora derruba todos)
Debugging impossível (distributed tracing sem maturidade)
Custo cloud 5x (cada serviço tem seu cluster, seu banco, seu logging)

É o pior dos dois mundos: complexidade de microserviços + acoplamento de monolito. Reconhecer distributed monolith em proposta do cliente é skill comercial valiosa.

2. Modular monolith: a saída elegante de 2026

Solução que combina o melhor: organização de microserviços + simplicidade operacional de monolito.

O que é

Modular monolith: aplicação única (1 deploy, 1 banco, 1 runtime), mas internamente organizada em módulos com fronteiras explícitas. Cada módulo tem:

API pública (interface) e implementação privada (esconder detalhes)
Schema próprio no banco (ou schema separado)
Testes próprios
Responsabilidade clara (Single Responsibility)

Módulos comunicam via API interna (chamada de função, não HTTP). Sem latência de rede. Sem distributed tracing. Mas com fronteiras claras pra evoluir.

Como Shopify, Basecamp, Square, Stack Overflow fazem

Shopify processa Black Friday (~50M req/min em pico) num modular monolith Ruby on Rails chamado internamente de "the core". Têm 60+ módulos com fronteiras explícitas, gerados por uma ferramenta chamada Packwerk que impede módulo A de importar internals de módulo B.

Basecamp (de DHH, criador do Rails) opera serviço SaaS B2B com 100k+ clientes num majestic monolith de ~1.000 KLOC.

Square (pagamentos) tem partes em microserviços por compliance (PCI scope), mas o core é modular monolith.

Stack Overflow processa 1.3 bilhão de pageviews/mês num monolith ASP.NET com 9 servidores. Caso clássico que viralizou em 2016 e segue vivo.

Por que virou padrão pra startups crescendo

Em 2020-2025 surgiram ferramentas pra fazer modular monolith bem:

Packwerk (Ruby) - enforces module boundaries
modulith (Spring Java) - anotações pra módulos
Vertical Slice Architecture (.NET) - organização por feature, não por camada
NestJS Modules (Node.js/TypeScript) - módulos com DI
Nx workspaces (TypeScript) - monorepo com módulos isolados

Receita prática: comece monolito, organize em módulos desde dia 1, extraia microserviço só quando dor concreta justificar.

3. CAP theorem revisitado (em decisões reais)

Você viu CAP na Semana 2 (NoSQL). Aqui aplico em decisões arquiteturais práticas.

Recap rápido

CAP: em sistema distribuído, durante partição de rede, você escolhe Consistency OU Availability. Não tem como ter os dois ao mesmo tempo.

CP: pendências de consistência - sistema fica indisponível em vez de retornar dado errado
AP: pendência de disponibilidade - sistema responde sempre, mesmo que com dado desatualizado

Trade-offs práticos em decisões reais

Quando escolher CP: - Sistema bancário/financeiro - você não pode debitar 2x da mesma conta - Inventário de e-commerce com produto único (carros usados, leilão) - não pode vender 2x - Reserva de evento com lugar específico

Quando escolher AP: - Feed de rede social - pode mostrar contagem ligeiramente diferente entre usuários por segundos - Catálogo de produto de e-commerce - pode estar desatualizado por minutos - Sistema de analytics - agregação eventual é OK

Exemplos concretos: Postgres = CP, Cassandra = AP

Postgres (e maioria SQL): prioriza consistência. Em replicação, se réplica perde conexão com primário, prefere ficar offline em vez de servir dado stale.

Cassandra/DynamoDB: prioriza disponibilidade. Aceita "eventual consistency" - escrita pode aparecer em réplicas com lag de milissegundos a segundos, mas sistema sempre responde.

MongoDB: CP por padrão (replica set com leitura no primário; durante partição, a minoria sem primário recusa operações em vez de servir dado divergente). Pode relaxar pra leituras em secundários, ficando eventualmente consistente.

Redis Cluster: AP por padrão.

Em reunião com arquiteto: a pergunta "por que escolheram Postgres em vez de Cassandra?" tem resposta "porque nossos casos de uso exigem consistência forte" - não "porque Postgres é melhor". Não tem melhor; tem adequado ao caso.

4. Event-driven architecture

Arquitetura onde componentes se comunicam publicando e consumindo eventos em vez de fazer chamadas síncronas request/response.

Pub/Sub vs Request/Response

Request/Response (síncrono): - A chama B, espera resposta de B - Latência soma (se B chama C, total = A→B + B→C + processamento) - Acoplamento alto (A precisa saber que B existe) - Falha de B = falha de A

Pub/Sub (assíncrono): - A publica evento "PedidoCriado" num broker - B, C, D consomem o evento independentemente - A não sabe quem consome - A continua mesmo se B/C/D estão fora - Latência pra A = só publicação no broker (~ms)

Quando event-driven vence

Vence quando: - Múltiplos consumidores reagem ao mesmo evento (notificação, analytics, fulfillment, faturamento - todos querem saber "pedido foi criado") - Latência de quem produz não pode depender de quem consome (pedido é criado em 50ms mesmo que faturamento demore 5s) - Resiliência via desacoplamento (broker armazena evento, consumidores processam quando voltarem online) - Audit trail naturalmente vira eventos persistidos - Escala assimétrica (um produtor, muitos consumidores em paralelo)

Quando event-driven piora tudo

Piora quando: - Transação ACID é necessária (você quer "tudo ou nada" - eventos têm consistência eventual) - Debugging de fluxo virou pesadelo (10 eventos pulam de serviço pra serviço, qual gerou o bug?) - Order matters mas broker não garante (Kafka garante por partição; RabbitMQ não garante sem trabalho) - Time não tem maturidade pra observabilidade de eventos

Ferramentas em 2026

Apache Kafka - gold standard pra eventos em larga escala (LinkedIn, Uber, Netflix usam). Curva de aprendizado íngreme.
RabbitMQ - message broker tradicional. Ótimo pra começar. Sintaxe AMQP.
AWS SQS + SNS - managed, simples, integra com tudo da AWS. Latência maior que Kafka.
Google Pub/Sub - managed, escala automática. Bom em GCP.
NATS - leve, performante, menos features que Kafka. Cresceu em popularidade 2023-2026.
Redpanda - Kafka-compatible mas escrito em C++, sem JVM. Mais leve, performance similar.
AWS Kinesis - Kafka-like managed AWS.

Cenário Team Studio típico

Cliente tem evento "PedidoCriado" no e-commerce dele. Team Studio (agente de atendimento) consome esse evento pra enviar mensagem WhatsApp confirmando. Cliente não precisa modificar o e-commerce - basta expor o evento num webhook (que você viu na Semana 8) ou num tópico de pub/sub.

Pra clientes maiores com Kafka interno: Team Studio se conecta como Kafka consumer com consumer-group próprio. Cada evento relevante vira ação de agente.

5. Padrões arquiteturais comuns

Seis padrões que aparecem em conversa com arquiteto sênior.

API Gateway

O que é: ponto único de entrada que recebe todas as requisições externas e roteia pra serviços internos.

Funcionalidades comuns: autenticação, rate limiting, caching, logging, transformação de payload, agregação de respostas.

Ferramentas: Kong, AWS API Gateway, Azure API Management, Apigee (Google), Traefik, nginx com módulos.

Quando vale: sempre que você tem mais de 2-3 serviços expostos publicamente. Sem gateway, cada serviço tem que implementar auth/logging/rate-limit por conta.

BFF (Backend for Frontend)

O que é: serviço backend dedicado a um tipo específico de cliente (web, mobile iOS, mobile Android, smart TV).

Por que existe: cada frontend tem necessidades diferentes. Mobile quer payload pequeno, web pode receber payload completo. Em vez de cada frontend chamar 5 microserviços, BFF agrega tudo.

Quando vale: quando você tem frontends muito diferentes consumindo backend muito complexo. Para PME com web + mobile híbrido, BFF é overkill.

Ferramentas: GraphQL frequentemente usado como BFF (você viu na Semana 8). Mas BFF pode ser REST/gRPC também.

Sidecar

O que é: processo separado rodando ao lado da aplicação (mesmo container/pod) que oferece capacidades cross-cutting (logging, monitoring, service mesh, auth).

Exemplo clássico: Envoy proxy como sidecar em Kubernetes. Aplicação fala HTTP local com Envoy, Envoy faz mTLS + retry + circuit breaker + observability transparente.

Quando vale: arquitetura microserviços já madura com service mesh (Istio, Linkerd). Pra monolito é overkill.

Saga

O que é: padrão pra transações distribuídas em arquitetura sem ACID transacional global. Quebra "transação" em série de passos com compensação se um falhar.

Cenário: criar pedido envolve (1) reservar estoque + (2) cobrar cartão + (3) emitir nota fiscal + (4) agendar entrega. Cada passo é em serviço diferente. Se (3) falha, você precisa desfazer (1) e (2).

Duas variantes: - Choreography: cada serviço escuta eventos e age. Sem coordenador central. Bom pra fluxos simples. - Orchestration: coordenador central (saga orchestrator) chama serviços em sequência. Bom pra fluxos complexos.

Ferramentas: Temporal.io, AWS Step Functions, Camunda, Zeebe, Apache Airflow (também serve).

Quando vale: quando você tem fluxo de negócio crítico envolvendo múltiplos serviços e precisa de consistência eventual com compensação garantida.

Circuit Breaker

O que é: padrão de resiliência que abre (interrompe chamadas) quando serviço dependente está falhando, dando tempo pra ele se recuperar sem ser martelado.

3 estados: - Closed: tudo normal, chamadas passam - Open: serviço falhando, chamadas falham imediatamente (sem martelar dependência) - Half-Open: depois de timeout, deixa passar 1 chamada de teste. Se passar, volta pra Closed. Se falhar, volta pra Open.

Ferramentas: Hystrix (Netflix, deprecated mas histórico), Resilience4j (Java), Polly (.NET), opossum (Node.js), implementação manual em qualquer linguagem.

Quando vale: sistemas distribuídos com dependências de rede. Sem circuit breaker, falha em serviço externo derruba seu sistema inteiro por timeout.

Bulkhead

O que é: isolamento de recursos pra que falha em uma parte não afete outras. Vem de termo náutico: navios têm compartimentos estanques pra não afundarem se um for furado.

Exemplo prático: thread pools separadas pra cada dependência externa. Se um serviço externo trava, só uma thread pool fica esgotada - as outras continuam funcionando.

Quando vale: aplicações com múltiplas dependências externas críticas. Combinado com Circuit Breaker é muito poderoso.

6. Anti-padrões arquiteturais

Seis erros comuns em propostas arquiteturais. Reconhecer = comercial.

1. Distributed Monolith (já vimos)

Já cobrimos na seção 1. Sintomas: - Banco compartilhado entre microserviços - Deploy coordenado obrigatório - Mudança em um serviço quebra outros - Latência cumulativa absurda

2. Premature Optimization

Donald Knuth (1974): "Premature optimization is the root of all evil."

Aplicado a arquitetura: implementar Kubernetes + microserviços + Kafka + Cassandra antes de ter 100 usuários ativos. Você gasta meses configurando infraestrutura pra escala que talvez nunca venha, em vez de validar produto.

Sintoma em proposta: arquiteto júnior gostando de complexidade. "Vamos preparar pra 1 milhão de usuários" quando sistema tem 50.

Resposta saudável: começar simples (monolito modular + banco managed + deploy serverless ou container simples). Escalar quando dor real aparecer.

3. God Service

O que é: dentro de arquitetura microserviços, um serviço enorme que faz 80% do trabalho enquanto outros 12 fazem 20%.

Sintomas: - Time inteiro só consegue trabalhar no god service - Outros serviços são meros CRUDs sem lógica - Mudança no god service é coordenação infinita - O god service vira "novo monolito"

Solução: refatorar god service em módulos com fronteiras explícitas, depois extrair serviços só quando justificável.

4. Database Shared Entre Microserviços

Sintoma: você tem microserviço A e microserviço B, mas ambos leem/escrevem na mesma tabela orders.

Por que é problema: - Mudança de schema afeta dois serviços - Acoplamento via banco (pior tipo de acoplamento - invisível, sem versionamento de API) - Performance ruim (lock contention entre serviços) - Impossível extrair serviço de verdade

Solução: cada serviço dono do schema dele. Quer compartilhar dado? Via API ou evento. Sem exceção.

5. Synchronous Chains Profundas

Sintoma: requisição do usuário faz chamada síncrona em cadeia: A → B → C → D → E. Latência total = soma das partes. Se E está lento, tudo está lento. Se E falha, tudo falha.

Por que ruim: - Latência cumulativa - Falhas cascateadas (E cai = todos caem) - Acoplamento temporal (todos precisam estar UP simultaneamente) - Recursos ociosos esperando resposta

Solução: tornar parte assíncrona (event-driven). Ou usar Circuit Breaker + timeout agressivo + fallback gracioso.

6. YAGNI Violation

YAGNI: "You Aren't Gonna Need It" (Kent Beck, Extreme Programming).

Sintoma em arquitetura: implementar abstrações pra "futuras necessidades" que provavelmente nunca virão. Interface genérica pra "qualquer banco" quando você só usa Postgres. Plugin system pra "qualquer tipo de pagamento" quando você só processa Pix.

Custo: complexidade pesa em manutenção, performance, time-to-market. Você paga hoje por flexibilidade que talvez nunca use.

Solução: implementar pra necessidade atual + 1 nível de flexibilidade óbvia. Refatorar quando segunda necessidade real aparecer.

7. ADR (Architecture Decision Records)

Por que ADR existe

Toda decisão arquitetural tem contexto e trade-offs. Daqui 6 meses, alguém vai perguntar "por que escolhemos Supabase em vez de Postgres self-hosted?" Se você não documentou, vai esquecer (ou ninguém vai saber).

ADR é documento curto (1-2 páginas) registrando uma decisão arquitetural com contexto, alternativas consideradas, decisão tomada e consequências esperadas.

Template MADR (Markdown Architectural Decision Record)

Versão mais popular em 2026: MADR (https://adr.github.io/madr/). Template:

# ADR-001: [Título curto da decisão]

## Status
[proposed | accepted | deprecated | superseded by ADR-XYZ]

## Context
Por que precisamos tomar essa decisão? Qual o problema?

## Decision
O que decidimos fazer?

## Consequences
Quais são os impactos positivos, negativos e neutros?

## Alternatives Considered
- Opção A: prós e contras
- Opção B: prós e contras

Onde guardar

Convenção: docs/adr/ na raiz do repo. Arquivos numerados sequencialmente: 0001-titulo-da-decisao.md, 0002-....

Quando escrever ADR

Escolha de tecnologia (banco, linguagem, framework, cloud)
Padrão arquitetural adotado/rejeitado
Trade-off significativo entre opções
Decisão que afeta múltiplos times
Decisão que tem chance de ser questionada no futuro

Não escrever ADR pra: - Decisões reversíveis fáceis (cor de botão) - Implementação detalhada (isso é código/PR) - Decisões individuais sem impacto sistêmico

Exemplo prático Team Studio

docs/adr/0001-supabase-vez-de-postgres-self-hosted.md

# ADR-001: Usar Supabase managed em vez de Postgres self-hosted

## Status
Accepted (2026-01-15)

## Context
Mission Control da Terapeuta Multimídia precisa de Postgres com Row
Level Security + Auth + Storage + Realtime. Time é 1 pessoa (George).
Operar Postgres em produção exige conhecimento de backup, replicação,
patches, scaling vertical. Não é diferencial competitivo da TM.

## Decision
Usar Supabase managed em conta da TM. Configurar 4 projetos
separados por dor de cliente:
- xbfilqbtwwbsuhrfafmw: Mission Control + tm-presenca
- rcoqj...: Agenda TM
- djygm...: SaaS DSN
- eqgs...: Doutor Multimídia

## Consequences
Positivos:
- Zero esforço operacional (backup, patches, monitoring)
- RLS nativo cuida de isolamento multi-tenant
- Auth + Storage + Realtime gratis no pacote
- Escala horizontal automática

Negativos:
- Vendor lock-in (migrar pra Postgres puro custaria semanas)
- Custo cresce com uso (vs custo fixo de VPS)
- Latência ligeiramente maior que Postgres na mesma VPS

Neutros:
- 4 projetos = isolamento forte entre operações de clientes
- Sentry-style observability via Supabase Studio

## Alternatives Considered
- Postgres self-hosted na VPS Hostinger: descartado pelo
  esforço operacional não-diferencial
- PlanetScale (MySQL serverless): descartado por não ter
  Row Level Security
- AWS RDS Postgres: descartado por custo 3-4x maior pro
  tamanho atual

ADR vira artefato comercial poderoso quando cliente pergunta "por que vocês usam Supabase?". Você manda o ADR.

8. Arquitetura Team Studio hoje (caso concreto)

Aplico tudo nesta semana à arquitetura real do Team Studio, pra você ter referência.

Mapa atual

Camada cliente (browser/mobile): - Mission Control (Next.js 15 + React 19 + Supabase Auth) - operação interna - Sites de clientes em HTML/CSS estático (servido por Caddy) - Apps studio do Davi (Pixel-Forge, ferramentas) em Express

Camada aplicação (VPS Hostinger SP): - Caddy reverse proxy (TLS, roteamento de 30+ domínios) - Docker (Evolution API, n8n, Postgres dedicado pra Evolution) - PM2 (4 processos Node.js) - Cron jobs (backup, monitoramento, ads automation)

Camada dados: - 4 projetos Supabase (multi-tenant via RLS) - 1 Postgres Evolution (mensagens WhatsApp, bind 127.0.0.1) - Sistema de arquivos local (uploads, backups locais) - Hostinger snapshot diário (DR)

Camada integração externa: - OpenAI/Anthropic (LLMs) - Meta Business APIs (Instagram, WhatsApp Business) - Asaas (cobrança brasileira) - Hotmart (infoprodutos) - Google APIs (Sheets, Drive, Calendar, Maps)

Padrões arquiteturais usados

✅ Modular monolith: Mission Control é Next.js único com módulos por área (CRM, Kanban, Financeiro, Estúdio). Sem microserviços.

✅ API Gateway implícito: Caddy faz roteamento + TLS pra todos serviços. Sem Kong/Apigee - Caddy basta.

✅ Multi-tenant via RLS: Supabase Row Level Security garante isolamento entre clientes na mesma tabela. Sem schema-per-tenant nem database-per-tenant.

✅ Event-driven parcial: webhooks Evolution → n8n → Mission Control formam fluxo assíncrono pra mensagens WhatsApp. Pedido criado em Hotmart → webhook → Mission Control.

✅ Sidecar logging: cada container tem stdout/stderr capturado pelo Docker, agregado em logrotate.

Padrões evitados conscientemente

❌ Microserviços: time = 1 pessoa. Modular monolith resolve.

❌ Kubernetes: 30+ sites em containers Docker no mesmo VPS funcionam. k8s seria overkill (vimos na Semana 6).

❌ Kafka: Webhooks + Supabase Realtime resolvem todos os casos. Kafka seria overkill.

❌ API Gateway dedicado (Kong/Apigee): Caddy faz o trabalho com config simples.

❌ Service mesh (Istio/Linkerd): 0 microserviços = 0 mesh.

❌ CQRS (Command Query Responsibility Segregation): Postgres aguenta read+write no mesmo schema sem precisar separar.

Trade-offs feitos

Cada escolha veio com trade-off explícito:

VPS Hostinger vs hyperscaler: escolhemos VPS por custo (~R$ 200/mês) e simplicidade. Trade-off: escalabilidade vertical limitada, sem multi-region. Compensação: cliente que exigir multi-region paga upgrade pra AWS.
Supabase vs Postgres self-hosted: escolhemos managed (ADR-001). Trade-off: vendor lock-in. Compensação: contrato com Supabase + plano de saída documentado.
Monorepo vs polyrepo: escolhemos monorepo (sistema-multimidia/) com Mission Control + site Team Studio + docs + templates. Trade-off: git fica grande. Compensação: tooling moderno (Nx, Turborepo) lida com isso.

Próximas decisões (quando escalar)

Quando dor aparecer: - 50+ clientes Team Studio: avaliar Postgres self-hosted ou AWS RDS pra reduzir custo Supabase - 5+ desenvolvedores: começar modular monolith strict (Packwerk-style) - Cliente exigindo multi-region: migrar Mission Control pra AWS com sa-east-1 + us-east-1 - Volume eventos > 100k/dia: introduzir Kafka ou AWS SQS

Antes dessas dores, manter simplicidade vence.

9. 5 perguntas pra reunião com CTO/arquiteto

Use em primeira reunião com arquiteto do cliente:

1. "Vocês são monolito modular ou microserviços? Por que escolheram isso?"

Por que: pergunta arquitetural neutra que abre conversa. Resposta revela maturidade do time. CTO bom vai responder com contexto (escala, tamanho de time). CTO ruim vai dizer "microserviços porque é moderno".

2. "Onde vocês têm transações ACID críticas vs onde aceitam eventual consistency?"

Por que: força arquiteto a articular fronteiras de consistência. Em uma resposta você sabe se ele pensa em CAP ou se vai improvisar.

3. "Quais são seus pontos de acoplamento entre serviços hoje? Banco compartilhado, APIs síncronas, eventos?"

Por que: distributed monolith aparece aqui se existir. Banco compartilhado + APIs síncronas em cadeia = red flag.

4. "Como vocês documentam decisões arquiteturais? Tem ADR?"

Por que: ADR é sinal de maturidade. Cliente que documenta decisões é cliente que pensa antes de fazer. Sem ADR, decisões viram folclore e ninguém sabe por que estamos na nuvem X em vez de Y.

5. "Onde Team Studio se encaixaria na arquitetura de vocês? Como serviço externo via API? Embedded? Como microserviço próprio rodando na infra?"

Por que: força arquiteto a pensar concretamente na integração. 3 opções típicas: - Externo via API: Team Studio roda na nossa infra, cliente chama nossa API - Embedded: cliente embute Team Studio dentro do produto dele (white-label) - Microserviço próprio: cliente roda Team Studio dentro da infra dele (mais complexo, requer suporte)

Em 90% dos casos a resposta certa é "externo via API". Mas deixar o arquiteto verbalizar a escolha dele te ajuda a propor adequadamente.

10. Exercício prático: avaliar arquitetura proposta

Cenário: Scale-up brasileira de logística (Última Milha Logística, ULM), 800 funcionários, R$ 250M/ano. Querem implantar Team Studio pra: - Atendimento WhatsApp 24h pra motoristas e clientes - Geração automática de relatórios pros 6 supervisores regionais - Análise de dados de entrega com insights pros donos

Arquiteto deles, João, propôs implantação com 12 microserviços:

tm-auth-service - autenticação dedicada
tm-chat-orchestrator - orquestra conversas WhatsApp
tm-llm-gateway - abstração sobre OpenAI/Anthropic
tm-knowledge-base - RAG sobre docs da ULM
tm-report-generator - geração de PDF
tm-data-analyzer - análise de dados
tm-notification-service - envio de notificação
tm-audit-logger - logs centralizados
tm-config-manager - feature flags + config
tm-template-engine - templates de mensagem
tm-rate-limiter - rate limiting cross-service
tm-cache-service - cache compartilhado

Cada microserviço rodaria em pod separado num cluster Kubernetes na infra deles.

Sua tarefa: avaliar a proposta. O que você responderia ao João?

Resposta esperada (passo a passo)

Análise inicial

A proposta é textbook distributed monolith em fase de incubação. 12 microserviços pra escopo de Team Studio (atendimento + relatórios + análise) é over-engineering severo. Sintomas:

Conway's Law violada: Team Studio é serviço operado por 1 pessoa (você). 12 microserviços precisariam de 4-8 squads pra operação saudável. Não tem.
Acoplamento sintético: 80% das chamadas seriam síncronas em cadeia (chat → auth → llm-gateway → kb → notification). Latência soma.
Operação proibitiva: 12 deploys, 12 dashboards, 12 alertas, 12 monitoramentos. ULM acabou de inventar fardo operacional pra equipe deles também.
Custo cloud 5-8x maior que monolito equivalente (cada serviço tem overhead de runtime + cluster + observability).

Proposta alternativa

Em vez disso, modular monolith Team Studio + integração externa via API. Estrutura:

Team Studio (na infra Team Studio, sa-east-1): - 1 Next.js + Express com 6 módulos internos: - auth-module - chat-module - llm-module - kb-module - report-module - analytics-module - 1 Postgres (Supabase ou RDS) - 1 deploy - 1 dashboard

Integração com ULM: - ULM expõe webhook pra mensagens WhatsApp → Team Studio consume - ULM expõe API REST pra dados de entrega → Team Studio polla (ou consome eventos se houver Kafka) - Team Studio expõe API pra ULM consultar status

Resultado: ~95% da complexidade da proposta original eliminada, com mesmo output. Custo cloud ULM reduzido. Velocidade de implantação 5-10x maior (1 semana vs 3 meses).

Como abordar João (sem ferir orgulho)

Comece elogiando: "Sua proposta tem visão arquitetural sólida - vejo princípios de Domain-Driven Design e separation of concerns aplicados."
Faça as perguntas certas (das 5 acima): "Qual seu time atual operando o backend? Vocês têm SRE dedicado? Quanto custa cada microserviço novo em infra/observabilidade?"
Apresente os trade-offs: "Os 12 microserviços fazem sentido se vocês têm 5+ squads dedicados e tráfego acima de X. Pra escopo Team Studio na fase atual, modular monolith vence em 4 dimensões: time-to-market, custo, manutenção, latência."
Ofereça evidência: mande ADR-001 + link pro post da Amazon Prime Video + post do Shopify modular monolith.
Negocie um meio-termo se preciso: "Se vocês tiverem preocupação específica com isolamento (compliance, escala futura), podemos começar monolito modular e extrair 1-2 serviços específicos quando dor concreta aparecer."

Output esperado: João respeita você como par técnico, recomenda Team Studio pra direção, contrato fecha em modelo simplificado.

Resumo de uma frase

Arquitetura boa é arquitetura adequada ao problema - em 2026, isso quase sempre significa modular monolith + integrações via API/eventos quando justificado, não 12 microserviços porque "é moderno" - e seu valor comercial em reunião com CTO é reconhecer over-engineering e propor caminho enxuto.

Próximos passos

Bloco F continua com semanas focadas em conversas comerciais com TI corporativo:

Semana 13: Métricas, SLA, RPO/RTO, métricas DORA - como prometer com segurança
Semana 14: Custo, pricing, TCO real, modelos de precificação
Semana 15: Reuniões com TI corporativo - táticas e armadilhas práticas
Semana 16: Vendor lock-in, exit strategy, checklist do CTO maduro (fecha trilha)

Glossário rápido (termos novos desta semana)

Conway's Law: sistemas refletem a estrutura de comunicação das organizações que os produzem
Modular monolith: aplicação única com módulos internos de fronteira explícita
Distributed monolith: anti-padrão de microserviços acoplados como monolito espalhado
God service: microserviço gigante que concentra 80% da lógica
YAGNI: "You Aren't Gonna Need It" - não implementar pra futuro hipotético
API Gateway: ponto único de entrada que faz auth/routing/rate-limit pra serviços internos
BFF (Backend for Frontend): backend dedicado a um tipo de cliente (web, mobile, TV)
Sidecar: processo auxiliar rodando ao lado da app (mTLS, observability)
Saga: padrão de transação distribuída com compensação em caso de falha
Circuit Breaker: padrão de resiliência que abre conexão com dependência falhando
Bulkhead: isolamento de recursos pra evitar falha cascateada
Packwerk: ferramenta Ruby pra enforce de fronteiras de módulo em monolito
ADR (Architecture Decision Record): documento curto registrando decisão arquitetural
MADR: template markdown popular pra ADR
CQRS (Command Query Responsibility Segregation): padrão que separa modelos de leitura e escrita
Event Sourcing: padrão onde estado é derivado de sequência de eventos persistidos
Eventual consistency: garantia de que estado converge eventualmente, sem ACID
Premature optimization: implementar complexidade pra escala que talvez nunca venha