Capstone: arquitetura multi-DB real

⏱ 20 min·⭐ 85 XP

Pré-requisitos (0/1)0%

⬜🧬 Vector DBs: pgvector, Pinecone, Weaviate, Qdrant(NoSQL + Vector Databases)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

Projeto proposto

Projete e implemente uma arquitetura polyglot realista para um SaaS de suporte ao cliente com IA. Requisitos: OLTP transacional, analytics em dashboards live, busca semântica em base de conhecimento (RAG), rate limiting + sessão, histórico de tickets pesquisável.

O capstone vale como peça de portfolio sênior: não é um CRUD, é decisão de arquitetura documentada com trade-offs reais.

Stack alvo

Banco	O que guarda	Por que NÃO os outros
Relacional	Entidades, transações, permissão	É onde a integridade referencial é barata
Chave-valor em memória	Sessão, limite de taxa, ranking	Volátil por natureza — perder é aceitável
Colunar	Eventos para análise	Consulta agregada sobre bilhões de linhas quebra o relacional
Vetorial	Vetores de busca semântica	Similaridade não é operação de banco relacional comum
Busca textual	Índice invertido	Relevância e ordenação por texto são um problema à parte
⚠ A parte difícil	Manter todos em sincronia	É aqui que o capstone é avaliado — captura de mudança, não escrita dupla

BancoRelacional

O que guardaEntidades, transações, permissão

Por que NÃO os outrosÉ onde a integridade referencial é barata

BancoChave-valor em memória

O que guardaSessão, limite de taxa, ranking

Por que NÃO os outrosVolátil por natureza — perder é aceitável

BancoColunar

O que guardaEventos para análise

Por que NÃO os outrosConsulta agregada sobre bilhões de linhas quebra o relacional

BancoVetorial

O que guardaVetores de busca semântica

Por que NÃO os outrosSimilaridade não é operação de banco relacional comum

BancoBusca textual

O que guardaÍndice invertido

Por que NÃO os outrosRelevância e ordenação por texto são um problema à parte

Banco⚠ A parte difícil

O que guardaManter todos em sincronia

Por que NÃO os outrosÉ aqui que o capstone é avaliado — captura de mudança, não escrita dupla

# Mapa de stores por responsabilidade

postgres:              # source of truth transacional
  responsabilidade: users, orgs, tickets, messages, billing
  por_que: ACID, FKs, JSONB flexivel, ecossistema
  exemplos_tables: users, tickets, messages, audit_log, outbox_events

redis:                 # latencia sub-ms, structures
  responsabilidade: session, rate limit, presence, cache hot
  por_que: estruturas (ZSET, Stream), TTL nativo, Lua atomico

clickhouse:            # analytics OLAP
  responsabilidade: eventos, metricas de produto, relatorios
  por_que: colunar + compressao, queries agregadas em bilhoes de rows
  ingestao: via CDC + Kafka engine

pgvector (mesmo Postgres): # busca semantica ate 5M vetores
  responsabilidade: knowledge base, similaridade entre tickets
  por_que: sem infra extra, join com tenant_id nativo, ACID

s3 + athena:           # cold storage / audit
  responsabilidade: logs > 18 meses, backup bruto
  por_que: custo marginal zero, query ad-hoc SQL

Fluxo CDC (consistência eventual)

-- Outbox pattern no Postgres
CREATE TABLE outbox_events (
    id          BIGSERIAL PRIMARY KEY,
    aggregate   TEXT NOT NULL,
    event_type  TEXT NOT NULL,
    payload     JSONB NOT NULL,
    created_at  TIMESTAMPTZ DEFAULT now()
);

-- Na mesma transacao do business write
BEGIN;
INSERT INTO tickets (id, org_id, subject, status)
  VALUES ($1, $2, $3, 'open');
INSERT INTO outbox_events (aggregate, event_type, payload)
  VALUES ('ticket', 'ticket.opened', jsonb_build_object(
    'ticketId', $1, 'orgId', $2, 'subject', $3
  ));
COMMIT;

# Debezium connector captura WAL e publica no Kafka
name: pg-outbox-connector
config:
  connector.class: io.debezium.connector.postgresql.PostgresConnector
  database.hostname: pg-primary
  database.dbname: app
  plugin.name: pgoutput
  publication.name: dbz_pub
  table.include.list: public.outbox_events
  transforms: outbox
  transforms.outbox.type: io.debezium.transforms.outbox.EventRouter
  transforms.outbox.route.topic.replacement: events.${routedByValue}

Quiz rápido

Qual é o principal risco de uma arquitetura com vários bancos especializados?

Entregáveis

# Capstone multi-DB — Entregáveis

## 1. Arquitetura
- Diagrama C4 (context, container, component)
- Data flow com CDC e stores derivados
- ADRs numerados: por que Postgres, por que Redis (e nao ZSET em Postgres), por que ClickHouse (e nao materialized views), por que pgvector (e nao Pinecone), quando migrar cada um

## 2. Implementação
- Postgres com schema real (users, orgs, tickets, messages, outbox)
- Redis com ZSET para sliding rate limit + Lua script versionado
- ClickHouse com MergeTree particionado + materialized view para rollup
- pgvector com HNSW + pipeline de reranker
- Debezium + Kafka (ou Redpanda) para CDC
- Dockerfile + docker-compose para reproducao local

## 3. Observability
- Metricas por store (latencia p50/p99, error rate, conexoes, cost/day estimado)
- Dashboard Grafana ou similar
- Alertas (p99 acima do SLO, lag de CDC > 30s, too many parts no CH)

## 4. SLOs e failover
- SLO por endpoint (ex: GET /tickets p99 < 150ms)
- Runbook de failover Postgres (promote replica)
- Runbook de degradacao Redis (cache bypass)
- Teste de chaos simples (matar replica, matar Debezium)

## 5. Writeup
- README principal com diagrama e decisoes
- Blog post ou doc de 2-4k palavras explicando o reasoning
- Cost breakdown mensal estimado (infra + observability)
- Limitations honestas e next iterations

O que separa sênior de pleno aqui

💡

Pleno entrega o código funcionando. Sênior entrega o código + ADRs mostrando alternativas rejeitadas + SLO + observability + cost awareness + runbook. Um hiring manager lendo esse writeup sabe em 10 minutos que você opera sistema real.

✅

Arquitetura polyglot é sobre disciplina, não sobre usar muitos bancos. Cada store a mais é custo operacional. Este capstone prova que você escolhe cada um por razão justificável — e sabe como manter consistência entre eles.

Perguntas frequentes

❓ Quando vale usar mais de um banco?

Quando há dor medida que o banco atual não resolve: latência de leitura que o cache resolve, análise que o colunar resolve, busca que o índice invertido resolve. Cada banco a mais é backup, monitoramento e conhecimento — e sem dor medida, é complexidade paga sem retorno.

❓ Como manter consistência entre bancos?

Definindo uma fonte de verdade e derivando o resto dela por evento ou captura de mudança — nunca escrevendo nos dois pelo código da aplicação. Escrita dupla sem transação distribuída divergem no primeiro erro parcial, e reconciliar depois é trabalho manual.

❓ Qual o maior risco de arquitetura com vários bancos?

Ninguém saber qual é a verdade. Quando dois sistemas discordam, sem fonte de verdade declarada a discussão é interminável. A regra que evita: um dono por dado, e todo o resto é cópia derivada que pode ser reconstruída.

Fixando

Quiz rápido

Por que a propagação por captura de mudanças é preferível a escrever nos dois bancos pela aplicação?

Quiz rápido

Que consistência a arquitetura do capstone assume, e o que isso exige do produto?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

📐

BM25 e TF-IDF: a math da busca clássica

Search & Information Retrieval Profundo · 13 min · +65 XP

→

Temas deste módulo

Discussão

Carregando comentários…

Capstone: arquitetura multi-DB real

⏱ 20 min·⭐ 85 XP

Pré-requisitos (0/1)0%

⬜🧬 Vector DBs: pgvector, Pinecone, Weaviate, Qdrant(NoSQL + Vector Databases)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

Projeto proposto

O capstone vale como peça de portfolio sênior: não é um CRUD, é decisão de arquitetura documentada com trade-offs reais.

Stack alvo

Banco	O que guarda	Por que NÃO os outros
Relacional	Entidades, transações, permissão	É onde a integridade referencial é barata
Chave-valor em memória	Sessão, limite de taxa, ranking	Volátil por natureza — perder é aceitável
Colunar	Eventos para análise	Consulta agregada sobre bilhões de linhas quebra o relacional
Vetorial	Vetores de busca semântica	Similaridade não é operação de banco relacional comum
Busca textual	Índice invertido	Relevância e ordenação por texto são um problema à parte
⚠ A parte difícil	Manter todos em sincronia	É aqui que o capstone é avaliado — captura de mudança, não escrita dupla

BancoRelacional

O que guardaEntidades, transações, permissão

Por que NÃO os outrosÉ onde a integridade referencial é barata

BancoChave-valor em memória

O que guardaSessão, limite de taxa, ranking

Por que NÃO os outrosVolátil por natureza — perder é aceitável

BancoColunar

O que guardaEventos para análise

Por que NÃO os outrosConsulta agregada sobre bilhões de linhas quebra o relacional

BancoVetorial

O que guardaVetores de busca semântica

Por que NÃO os outrosSimilaridade não é operação de banco relacional comum

BancoBusca textual

O que guardaÍndice invertido

Por que NÃO os outrosRelevância e ordenação por texto são um problema à parte

Banco⚠ A parte difícil

O que guardaManter todos em sincronia

Por que NÃO os outrosÉ aqui que o capstone é avaliado — captura de mudança, não escrita dupla

# Mapa de stores por responsabilidade

postgres:              # source of truth transacional
  responsabilidade: users, orgs, tickets, messages, billing
  por_que: ACID, FKs, JSONB flexivel, ecossistema
  exemplos_tables: users, tickets, messages, audit_log, outbox_events

redis:                 # latencia sub-ms, structures
  responsabilidade: session, rate limit, presence, cache hot
  por_que: estruturas (ZSET, Stream), TTL nativo, Lua atomico

clickhouse:            # analytics OLAP
  responsabilidade: eventos, metricas de produto, relatorios
  por_que: colunar + compressao, queries agregadas em bilhoes de rows
  ingestao: via CDC + Kafka engine

pgvector (mesmo Postgres): # busca semantica ate 5M vetores
  responsabilidade: knowledge base, similaridade entre tickets
  por_que: sem infra extra, join com tenant_id nativo, ACID

s3 + athena:           # cold storage / audit
  responsabilidade: logs > 18 meses, backup bruto
  por_que: custo marginal zero, query ad-hoc SQL

Fluxo CDC (consistência eventual)

-- Outbox pattern no Postgres
CREATE TABLE outbox_events (
    id          BIGSERIAL PRIMARY KEY,
    aggregate   TEXT NOT NULL,
    event_type  TEXT NOT NULL,
    payload     JSONB NOT NULL,
    created_at  TIMESTAMPTZ DEFAULT now()
);

-- Na mesma transacao do business write
BEGIN;
INSERT INTO tickets (id, org_id, subject, status)
  VALUES ($1, $2, $3, 'open');
INSERT INTO outbox_events (aggregate, event_type, payload)
  VALUES ('ticket', 'ticket.opened', jsonb_build_object(
    'ticketId', $1, 'orgId', $2, 'subject', $3
  ));
COMMIT;

# Debezium connector captura WAL e publica no Kafka
name: pg-outbox-connector
config:
  connector.class: io.debezium.connector.postgresql.PostgresConnector
  database.hostname: pg-primary
  database.dbname: app
  plugin.name: pgoutput
  publication.name: dbz_pub
  table.include.list: public.outbox_events
  transforms: outbox
  transforms.outbox.type: io.debezium.transforms.outbox.EventRouter
  transforms.outbox.route.topic.replacement: events.${routedByValue}

Quiz rápido

Qual é o principal risco de uma arquitetura com vários bancos especializados?

Entregáveis

# Capstone multi-DB — Entregáveis

## 1. Arquitetura
- Diagrama C4 (context, container, component)
- Data flow com CDC e stores derivados
- ADRs numerados: por que Postgres, por que Redis (e nao ZSET em Postgres), por que ClickHouse (e nao materialized views), por que pgvector (e nao Pinecone), quando migrar cada um

## 2. Implementação
- Postgres com schema real (users, orgs, tickets, messages, outbox)
- Redis com ZSET para sliding rate limit + Lua script versionado
- ClickHouse com MergeTree particionado + materialized view para rollup
- pgvector com HNSW + pipeline de reranker
- Debezium + Kafka (ou Redpanda) para CDC
- Dockerfile + docker-compose para reproducao local

## 3. Observability
- Metricas por store (latencia p50/p99, error rate, conexoes, cost/day estimado)
- Dashboard Grafana ou similar
- Alertas (p99 acima do SLO, lag de CDC > 30s, too many parts no CH)

## 4. SLOs e failover
- SLO por endpoint (ex: GET /tickets p99 < 150ms)
- Runbook de failover Postgres (promote replica)
- Runbook de degradacao Redis (cache bypass)
- Teste de chaos simples (matar replica, matar Debezium)

## 5. Writeup
- README principal com diagrama e decisoes
- Blog post ou doc de 2-4k palavras explicando o reasoning
- Cost breakdown mensal estimado (infra + observability)
- Limitations honestas e next iterations

O que separa sênior de pleno aqui

💡

✅

Perguntas frequentes

❓ Quando vale usar mais de um banco?

❓ Como manter consistência entre bancos?

❓ Qual o maior risco de arquitetura com vários bancos?

Fixando

Quiz rápido

Por que a propagação por captura de mudanças é preferível a escrever nos dois bancos pela aplicação?

Quiz rápido

Que consistência a arquitetura do capstone assume, e o que isso exige do produto?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

📐

BM25 e TF-IDF: a math da busca clássica

Search & Information Retrieval Profundo · 13 min · +65 XP

→

Temas deste módulo

Discussão

Carregando comentários…