Polyglot Persistence

Múltiplos bancos na mesma arquitetura — cada padrão de acesso ao seu banco

Polyglot persistence é a consequência natural da decision tree de banco: nenhum banco é bom em tudo, então use cada um para o que ele faz melhor. Conecta diretamente com CQRS — read models e write models podem (e frequentemente devem) viver em bancos diferentes.

Arquitetura típica

API (ASP.NET Core)Write sidePostgreSQLSource of truth · ACIDOutbox → KafkaEvent log + replayRead sideRedisHot cache · O(1)OpenSearchFull-text · facetsNeptune / FusekiGraph · relationswritesoutboxprojectionsreads

Fluxo

  1. Writes vão pro source of truth (Postgres) — único responsável por ACID
  2. Outbox (mesma transação) registra evento de mudança (ver página dedicada)
  3. Debezium / dispatcher propaga o evento pro Kafka (ver CDC)
  4. Consumers projetam o evento em cada read model (Redis, OpenSearch, Graph)
  5. Reads escolhem o read model conforme o caso de uso
Read models são eventualmente consistentes com o source of truth. Tipicamente milissegundos a alguns segundos atrás. Se a UX exige "leu o que acabei de escrever", você lê do source of truth direto OU usa "read your own writes" via sticky session ao primário.