Skip to content

Instantly share code, notes, and snippets.

@gbzarelli

gbzarelli/0001-database-choise.md

Last active February 4, 2025 19:31
Show Gist options
  • Save gbzarelli/a5a175230c0e2e9996d6e40c549082be to your computer and use it in GitHub Desktop.
Save gbzarelli/a5a175230c0e2e9996d6e40c549082be to your computer and use it in GitHub Desktop.
Download ZIP
Exemplo de ADR #helpdev-blog
Raw
0001-database-choise.md

Escolha do Banco de Dados para o Serviço de Catálogo

Data: 07/01/2025
Status: Aprovado

Contexto:

Precisamos de um banco de dados para armazenar informações de produtos, incluindo descrições, preços e categorias. O sistema deve suportar um alto volume de consultas e permitir buscas eficientes.

Decisão:

Optamos por usar PostgreSQL como banco de dados principal, devido à sua flexibilidade em consultas complexas e suporte a indexação avançada.

Alternativas Consideradas:

  • MongoDB: Oferece escalabilidade horizontal, mas tem menos suporte para consultas SQL complexas.
  • DynamoDB: Alta disponibilidade e escalabilidade automática, mas custo imprevisível e suporte limitado a queries flexíveis.

Consequências:

✅ Facilidade de integração com ferramentas analíticas.
✅ Maior controle sobre a modelagem dos dados.
⚠️ Pode exigir otimizações para suportar grandes volumes de leitura/escrita.

Raw
0002-cache-performance.md

Escolha da Estratégia de Cache para Melhorar o Desempenho

Data: 07/01/2025
Status: Aprovado

Contexto

O sistema precisa melhorar o tempo de resposta de requisições frequentes, reduzindo a carga sobre o banco de dados. Atualmente, todas as consultas são realizadas diretamente no banco, causando latência em páginas com alto volume de acessos simultâneos.

Decisão

Optamos por utilizar Redis como camada de cache distribuída, armazenando respostas de consultas frequentes para reduzir o número de acessos ao banco de dados.

Alternativas Consideradas

  • Memcached: Rápido e eficiente, mas não oferece persistência nativa e tem menor flexibilidade para tipos de dados complexos.
  • Cache no próprio banco (PostgreSQL Materialized Views): Boa opção para dados estáticos, mas requer agendamentos para atualização, não atendendo bem a necessidade de cache dinâmico.

Consequências

✅ Redução significativa da latência em requisições repetitivas.
✅ Melhor escalabilidade, já que Redis pode ser distribuído e replicado.
⚠️ Necessidade de implementar estratégias de invalidação para evitar servir dados desatualizados.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment