Tema
System design.
19 textos sobre esse tema.
Desenhando uma API pensada para rastreabilidade
A maior parte das APIs devolve estado. Quem precisa provar o que aconteceu precisa de outra coisa, e isso muda o desenho desde o primeiro endpoint.
→SET 2026Retry, backoff e dead letter queue
Repetir a operação que falhou parece trivial. Feito errado, o retry transforma uma falha pequena numa queda geral.
→SET 2026Correlation ID, trace ID e span ID: quem é quem
Três identificadores que quase todo mundo mistura, e a diferença entre eles é o que permite responder o que aconteceu com aquela requisição.
→SET 2026Event sourcing: quando vale e quando é tiro no pé
Padrão poderoso, caro e adotado pelo motivo errado com frequência. Os quatro casos onde ele se paga.
→AGO 2026Monólito modular: a arquitetura que a maioria dos times deveria ter
A discussão monólito contra microserviço esconde a opção do meio, que é onde quase todo produto deveria estar.
→AGO 2026Outbox pattern no Postgres: mensagem e transação no mesmo commit
Gravar no banco e publicar na fila são duas operações que podem falhar separadamente. O outbox junta as duas num commit só.
→AGO 2026Merkle tree na prática: provar que nada foi alterado
A estrutura por trás do Git, do Bitcoin e do certificate transparency. Mais simples do que a fama sugere, e útil fora de blockchain.
→AGO 2026Audit trail que aguenta uma auditoria de verdade
Quase todo sistema tem uma tabela de log de alteração. Quase nenhuma responde as perguntas que aparecem quando a auditoria chega.
→AGO 2026Log append-only: a estrutura mais subestimada de arquitetura
Uma tabela onde só se insere resolve rastreabilidade, auditoria, integração e boa parte dos bugs de concorrência. E quase ninguém começa por ela.
→AGO 2026UUIDv7, ULID ou Snowflake: identificadores que não sabotam seu índice
UUIDv4 como chave primária é a decisão mais fácil de tomar e uma das mais caras de manter. Existe alternativa.
→AGO 2026Idempotência: a chave que salva sua API de cobrar duas vezes
Rede falha no meio. O cliente não sabe se deu certo e tenta de novo. O que acontece depois disso é decisão de arquitetura.
→AGO 2026Como eu enxergo a arquitetura do LinkedIn
A empresa que resolveu o problema de integração entre sistemas transformando o log num produto. É por isso que o Kafka existe.
→AGO 2026Como eu enxergo a arquitetura do Spotify
Dois sistemas escondidos num só: um orçamento de latência medido em milissegundos, e um log de eventos que também é a contabilidade.
→AGO 2026Como eu enxergo a arquitetura do WhatsApp
Criptografia ponta a ponta não é uma funcionalidade. É uma restrição que decide o que o servidor pode fazer, e ela simplifica mais do que complica.
→AGO 2026O que é hash criptográfico, explicado para quem constrói sistema
Sem analogia de liquidificador. O que a função garante, o que ela não garante, e onde o uso errado aparece em produção.
→AGO 2026Como eu enxergo a arquitetura do YouTube
Upload não é uma requisição, é um pipeline. E a recomendação não escolhe o melhor vídeo: ela elimina quase todos antes de escolher.
→AGO 2026Como eu enxergo a arquitetura do Instagram
O sistema mais impressionante da série é o mais entediante. E o identificador deles carrega a resposta pra um problema que quase todo mundo resolve errado.
→AGO 2026Como eu enxergo a arquitetura do Twitter (X)
Uma timeline não é uma consulta. É um resultado calculado antes de alguém pedir, e é essa inversão que sustenta o produto inteiro.
→AGO 2026Como projetar um sistema de rastreabilidade com hash único
Gerar um hash é fácil. Difícil é responder, seis meses depois, o que aquele hash prova. Um projeto de ponta a ponta.
→