Armazenar e consultar histórico de transações para centenas de milhões de contas

Question

IT Interview Practice · Accepted Answer

**Particione o razão (ledger) por conta e tempo, mantenha dados recentes quentes e dados antigos frios, e trate as linhas como um razão imutável append-only — para que o histórico de uma única conta seja uma fatia pequena e indexada, nunca um scan de bilhões de linhas.** O padrão de acesso é sempre "uma conta, um intervalo de datas", então particione para corresponder a isso.

## Arquitetura

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## Como funciona

- **Particione por conta + tempo.** Faça hash do id da conta em N buckets, depois particione por range por mês. Uma consulta por uma conta/mês bate em exatamente uma partição — o DB faz pruning do resto. Isso limita toda leitura independentemente do tamanho total.
- **Razão imutável.** Nunca faça `UPDATE` em uma transação; correções são novas linhas de reversão. Isso dá uma trilha de auditoria, replicação segura e permite cachear agressivamente (as linhas nunca mudam).
- **Tiering quente/frio.** Mantenha os últimos ~3 meses em SSD/Postgres rápido para leituras de baixa latência; migre partições mais antigas para **S3/Parquet** (consultado via Athena/Trino) ou Glacier. 95% das consultas batem em dados recentes, então a maior parte do armazenamento pode ser barata.
- **Paginação keyset.** Pagine com `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — não `OFFSET`. Offset escaneia e descarta linhas puladas; keyset busca o índice diretamente, O(1) por página.

## Perspectiva de entrevista

O entrevistador sonda **escolha da partition key** e **paginação**. Boas respostas dizem "particionar por conta"; respostas excelentes explicam **por que keyset supera OFFSET** em páginas profundas, por que o **razão é imutável** (auditabilidade, sem contenção de lock) e como o **tiering** corta custo. Uma armadilha é uma única tabela gigante com um índice composto — funciona até o índice não caber mais em RAM e toda leitura virar limitada por disco.

## Trade-offs e falhas

- **A partition key é difícil de mudar.** Escolha conta+tempo de antemão; re-particionar centenas de milhões de linhas depois é um projeto de migração.
- **Consultas cross-account sofrem.** "Volume total entre todas as contas" agora faz fan-out entre partições — empurre essas para um rollup OLAP.
- **Leituras frias são lentas.** Buscar um extrato de 3 anos do Glacier leva minutos; ajuste as expectativas do usuário ou faça pré-aquecimento sob demanda.
- **Partições quentes.** Uma conta baleia ou o mês atual pode ser um hotspot; faça sub-particionamento ou cacheie.
- **Quando não usar:** milhões de linhas (não centenas de milhões) cabem em uma única tabela Postgres indexada — não construa tiering que você não precisará. Recorra a isso na escala em que o índice de uma única tabela para de caber na memória.

Arquitetura

Como funciona

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas