Nem todo sistema precisa de um banco de dados transacional. Às vezes, persistência simples — com trade-offs explícitos — é a decisão correta.
Este repositório acompanha o artigo “Nem todo sistema precisa de um banco de dados: uma decisão arquitetural contextual”, cujo objetivo é discutir quando bancos transacionais são excesso e quando abordagens de persistência mais simples fazem mais sentido, sob a ótica de contexto, custo e maturidade do sistema.
Este não é um repositório de código produtivo nem uma biblioteca reutilizável.
O objetivo é:
Arquitetura madura não é maximalista. Ela é contextual, consciente e evolutiva.
Em determinados cenários, soluções de persistência tabular acessadas por API — como Google Sheets + Google Apps Script — podem ser arquiteturalmente válidas, desde que:
O argumento não é de equivalência técnica, mas de adequação ao problema.
.
├── artigo/
│ ├── artigo_arquitetura_DB.docx # Versão editável (Word)
│ └── artigo_arquitetura_DB.pdf # Versão para leitura
├── diagramas/
│ ├── arquitetura.mmd # Diagramas de arquitetura
│ └── fluxo-seguranca.mmd
└── README.md # Este arquivo
sequenceDiagram
participant C as Cliente
participant API as Apps Script
participant GS as Google Sheets
C->>API: HTTP Request
API->>GS: Leitura / Escrita
GS-->>API: Dados
API-->>C: JSON
O foco não é “substituir backends tradicionais”, mas reduzir fricção quando a complexidade da infraestrutura é maior que o problema resolvido.
Esta abordagem não é ACID e não escala indefinidamente.
Limitações reais incluem:
Essas limitações não são ignoradas — elas fazem parte da decisão.
✔ Faz sentido quando:
✖ Evite quando:
Este repositório não defende Sheets como solução universal.
Outras opções de baixa fricção incluem:
O ponto central permanece: escolha por contexto, não por dogma.
Este projeto é um convite à reflexão arquitetural.
Antes de perguntar:
“Qual banco de dados usar?”
Talvez a pergunta correta seja:
“Qual nível de persistência esse problema realmente exige agora?”