Simulador de Decisões

Aos 4 meses, a equipe concluiu 30% do trabalho. O monólito continua recebendo novas features porque o negócio não pode esperar. Agora você tem dois sistemas para manter e a equipe está dividida. O CTO começa a perguntar quando vai ficar pronto.

Lição: Reescritas completas quase nunca terminam no prazo. O negócio não para enquanto você reescreve.

Aos 3 meses, você extraiu o serviço de notificações. Os deploys do monólito ficaram um pouco mais rápidos. A equipe aprendeu sobre comunicação entre serviços, service discovery e monitoramento distribuído. Agora você pode planejar a próxima extração com mais confiança.

Lição: O padrão Strangler Fig permite migrar gradualmente com risco controlado. Cada extração ensina lições para a próxima.

Aos 2 meses, o monólito está organizado em módulos com interfaces claras. Os conflitos de merge caíram 60%. Os deploys ainda demoram 45 minutos, mas agora você pode fazer deploys parciais por módulo. A equipe tem uma base sólida para extrair serviços no futuro, se necessário.

Lição: Às vezes a melhor arquitetura distribuída é a que você não precisa. Um monólito bem organizado pode escalar mais do que você imagina.

O PostgreSQL lida bem com as 500K linhas e com as consultas complexas. Aos 6 meses, as leituras começam a saturar o banco de dados. Você adiciona uma read replica e o problema é resolvido. O histórico de alterações você implementa com uma tabela de auditoria e triggers.

Lição: PostgreSQL é uma escolha sólida para a maioria dos casos. Não subestime até onde um banco de dados relacional bem configurado pode chegar.

O MongoDB funciona bem no início. Aos 3 meses, você descobre que as consultas de agregação com múltiplos filtros são mais lentas do que o esperado. O schema flexível causou inconsistências nos dados porque diferentes partes da equipe salvavam os documentos com estruturas ligeiramente diferentes.

Lição: A flexibilidade de schema é uma faca de dois gumes. Sem disciplina, gera dívida técnica. O MongoDB brilha quando o modelo de dados é genuinamente hierárquico.

A combinação funciona muito bem para as leituras. Mas aos 2 meses, você descobre bugs de invalidação de cache: alguns usuários veem dados stale depois das atualizações. Você implementa um sistema de invalidação baseado em eventos e o problema é resolvido, mas a complexidade operacional aumentou significativamente.

Lição: Adicionar cache resolve problemas de desempenho, mas introduz problemas de consistência. Só adicione cache quando realmente precisar, não “só por precaução”.

Funciona, mas a reconciliação entre dois provedores é complexa. Alguns pagamentos são processados no Stripe e outros no PayPal, o que complica os relatórios financeiros. Além disso, o PayPal tem sua própria taxa de falhas — não é imune. Aos 3 meses, você tem um sistema mais resiliente, porém significativamente mais complexo de operar.

Lição: Múltiplos provedores aumentam a disponibilidade, mas multiplicam a complexidade. Avalie se o custo operacional justifica a melhoria na disponibilidade.

Os reenvios automáticos resolvem 90% das falhas transitórias. Mas você descobre um problema: alguns pagamentos são processados duas vezes porque o reenvio chega quando o Stripe já havia processado o primeiro (mas respondeu com timeout). Você implementa idempotência com chaves únicas e o problema é resolvido.

Lição: Reenvios sem idempotência são perigosos. Sempre implemente idempotência antes de implementar reenvios automáticos.

O circuit breaker detecta as falhas em segundos e para de enviar requests ao Stripe. Os usuários veem uma mensagem clara: “O sistema de pagamentos está temporariamente indisponível. Seu carrinho está salvo — você pode concluir a compra mais tarde.” A experiência não é perfeita, mas é honesta e não gera frustração.

Lição: Às vezes a melhor resposta a uma falha é ser transparente com o usuário. Nem todos os problemas exigem soluções técnicas complexas.