Construindo uma busca por filtros

Durante algum tempo, usei uma pergunta de system design que começava com uma tabela pequena e terminava com centenas de milhões de itens, centenas de filtros, atualizações contínuas e dezenas de milhares de consultas por segundo.

O candidato podia escolher qualquer linguagem e usar servidores, discos, memória, switches e roteadores. O que não podia fazer era encerrar o problema recomendando uma tecnologia. Precisava construir a solução a partir de estruturas de dados, algoritmos e protocolos — e explicar o limite de cada etapa.

As restrições entram aos poucos; cada parte preserva o problema anterior.

As sete partes

1. A pergunta — unidade pesquisável, contrato, primeira consulta SQL e estimativas.
2. Filtros como conjuntos — dicionários, índices invertido e direto, conjuntos adaptativos, igualdade e faixa.
3. Contar facetas — navegação lateral, bases “todos menos um”, estratégias exatas e aproximação declarada.
4. Atualizar sem interromper — sobreposição base–delta, WAL, checkpoints, manifests, segmentos e compaction.
5. Ordenar e paginar — top k, poda por blocos, ordem total, cursor e snapshots.
6. Quando uma máquina não basta — roteamento semântico, micro-partições, scatter-gather, réplicas e rebalanceamento.
7. Fechar o contrato online — consenso, deploy, split/merge, freshness, recuperação, backpressure e verificação.

Mapa da arquitetura — visão consolidada do data plane, storage/write plane e control plane, com componentes, contratos e sequências de query, update, compactação, split e deploy.

Guia de leitura e implementação — papers e livros organizados pelos três planos, com uma sequência de pequenos projetos.

A série não propõe que todo marketplace deva implementar seu próprio mecanismo. O objetivo é recuperar os building blocks que tecnologias diferentes precisam combinar. Conhecê-los nos permite discutir garantias e trade-offs sem transformar um nome de produto em argumento de arquitetura.