Builder de Arquitetura

Construa uma arquitetura de software passo a passo escolhendo componentes, camadas e conexões de acordo com os requisitos do sistema.

Objetivo

Neste laboratório você vai projetar uma arquitetura de software do zero. Você partirá de um conjunto de requisitos de negócio e técnicos, e deverá escolher os componentes, camadas e conexões que melhor resolvam o problema proposto.

O objetivo não é chegar à “resposta certa” — mas sim praticar o processo de tomada de decisões arquiteturais com critério.

Cenário: Plataforma de e-commerce

Imagine que pedem a você para projetar a arquitetura de uma plataforma de comércio eletrônico com os seguintes requisitos:

Usuários concorrentes: até 10.000 simultâneos
Catálogo: 50.000 produtos com busca e filtros
Pagamentos: integração com pelo menos 2 provedores externos
Notificações: e-mail e push em tempo real
Disponibilidade: 99,9% de uptime

Passo 1 — Escolher o estilo arquitetural

Antes de pensar em tecnologias, defina o estilo geral:

Estilo	Vantagens	Desvantagens	Quando escolher?
Monólito modular	Simples de implantar, fácil de depurar	Escalabilidade limitada, acoplamento interno	Times pequenos, MVP
Microsserviços	Escalabilidade independente, deploy autônomo	Complexidade operacional, latência de rede	Times grandes, domínios claros
Híbrido	Equilíbrio entre simplicidade e escalabilidade	Exige disciplina nos limites	Crescimento gradual

Exercício

Diante do cenário, qual estilo você escolheria? Considere:

O tamanho do time disponível
A necessidade de escalar componentes de forma independente (catálogo vs pagamentos)
A complexidade operacional que você pode assumir

Passo 2 — Definir as camadas do sistema

Uma vez escolhido o estilo, defina as camadas principais:

Camada de apresentação

SPA, SSR ou site estático?
Você precisa de um BFF (Backend for Frontend)?
Como você trata a autenticação no frontend?

Camada de aplicação

Quantos serviços você precisa?
Como eles se comunicam entre si (sync vs async)?
Onde vive a lógica de negócio crítica?

Camada de dados

Um banco de dados ou vários?
SQL, NoSQL ou ambos?
Você precisa de cache? Onde?

Camada de infraestrutura

Cloud, on-premise ou híbrido?
Contêineres, serverless ou VMs?
Como você trata os segredos e a configuração?

Passo 3 — Conectar os componentes

Defina como as peças se comunicam:

[Frontend SPA]
    │
    ▼
[API Gateway / BFF]
    │
    ├──► [Servicio de Catálogo] ──► [PostgreSQL + Redis Cache]
    │
    ├──► [Servicio de Órdenes] ──► [PostgreSQL]
    │         │
    │         ▼
    │    [Event Bus]
    │         │
    │         ├──► [Servicio de Pagos] ──► [Proveedor Externo]
    │         └──► [Servicio de Notificaciones] ──► [Email/Push]
    │
    └──► [Servicio de Auth] ──► [Redis Sessions]

Perguntas-chave

O que acontece se o serviço de pagamentos não responder?
Como você garante que um pedido não seja processado duas vezes?
Onde você implementa os circuit breakers?
Como você trata a consistência eventual entre serviços?

Passo 4 — Avaliar trade-offs

Toda decisão arquitetural tem trade-offs. Documente os seus:

Decisão	Trade-off aceito	Mitigação
Microsserviços para catálogo e pagamentos	Maior complexidade operacional	Kubernetes + CI/CD automatizado
Event bus para comunicação async	Consistência eventual	Idempotência + retry com backoff
Redis como cache de catálogo	Dados potencialmente stale	TTL de 5 minutos + invalidação por eventos
PostgreSQL para dados transacionais	Escalabilidade vertical limitada	Read replicas + particionamento

Passo 5 — Validar contra os requisitos

Verifique se sua arquitetura atende a cada requisito original:

Suporta 10.000 usuários concorrentes? Onde está o gargalo?
A busca no catálogo é rápida? Você usa índices ou um mecanismo de busca?
Os pagamentos são resilientes a falhas do provedor?
As notificações chegam em tempo real?
Você consegue alcançar 99,9% de uptime com essa arquitetura?

Reflexão

Ao terminar, pergunte a si mesmo:

Qual foi a decisão mais difícil? Por quê?
O que você mudaria se o time fosse de 3 pessoas em vez de 15?
O que você mudaria se os requisitos de disponibilidade fossem 99,99%?
Existe algum componente que você poderia eliminar sem perder funcionalidade crítica?

A arquitetura perfeita não existe — mas uma arquitetura bem fundamentada e documentada é inestimável.