Arquitetura de referência: aplicação OLTP em 3 camadas

Aplicações de negócio clássicas (pedidos, pagamentos, estoque) executam um grande número de transações curtas, de linha única e críticas para a consistência (OLTP). Esta árvore mostra passo a passo, a partir da identificação do perfil de carga, quando introduzir o banco relacional primário, um pooler de conexões, read replicas, uma camada de cache, backup + PITR e monitoramento. O objetivo não é 'adicionar tudo de início', mas adicionar o componente certo à medida que cada gargalo é comprovado.

Qual é o seu perfil de carga: mix de transações e requisitos de consistência?

A primeira decisão em uma arquitetura OLTP é se a carga é realmente transacional (um mix curto de gravações e leituras que exige ACID). Os dados são naturalmente relacionais e a consistência é crítica (dinheiro, estoque, pedidos), a carga é majoritariamente de leitura, ou a carga ainda é muito baixa?

• Transações curtas, consistência forte (dinheiro/estoque/pedidos)
• As leituras predominam fortemente, poucas gravações, e o tráfego está crescendo
• A carga é muito baixa; a configuração mais simples basta?

Você escolheu o engine de banco principal, e está preocupado com escala?

Um engine relacional é a base certa para o núcleo transacional (PostgreSQL, MySQL/InnoDB, Oracle, SQL Server). Com a escolha do engine definida, a próxima questão é a escalabilidade: uma única instância basta por enquanto, ou o número de conexões e a carga de leitura estão aumentando?

• O engine está definido; uma única instância basta por enquanto
• O número de conexões disparou, os recursos estão se esgotando
• A carga de leitura está crescendo e sobrecarregando a instância primária de gravação

Como você vai escalar as leituras: réplica ou cache?

Se a carga de leitura está sobrecarregando a instância primária, há duas opções complementares. Leituras que toleram dados levemente atrasados, como relatórios/listagens, podem ser direcionadas para uma read replica; se os mesmos dados 'quentes' forem solicitados repetidamente, um cache com latência de microssegundos (Redis) alivia o banco.

• Muitas leituras de relatórios/listagens; um leve lag é aceitável
• Os mesmos dados populares são lidos repetidamente

Recomendação: comece com um único primário + pool + backup

Mantenha a arquitetura simples no início: uma única instância primária relacional, um pool de conexões à frente dela e backups regulares bastam. Adicione complexidade somente quando um gargalo medido exigir.

Recomendação: adicione um pooler de conexões

Em OLTP, quando cada instância da aplicação abre as próprias conexões, o banco primário sufoca com o overhead de memória e de escalonamento sob milhares de conexões. Colocar um pooler no meio compartilha um pequeno número de conexões reais com o banco entre muitos requests da aplicação.

Recomendação: adicione uma read replica

As gravações permanecem no primário enquanto o tráfego somente leitura (relatórios, listagens, busca) é direcionado para uma ou mais réplicas assíncronas alimentadas pelo primário. Isso libera o primário para gravações e leituras críticas para a consistência.

Recomendação: adicione uma camada de cache (Redis)

Se os mesmos dados populares (sessões, catálogo, perfis, fragmentos de página) são lidos repetidamente, coloque um cache em memória à frente do banco e atenda a maioria das leituras sem sequer chegar ao banco. A latência cai e o banco primário fica aliviado.