Tema: system-design
-
Passo a passo de um serviço de upload de arquivos: tickets de envio direto ao storage, varredura assíncrona e cotas
Um passo a passo de design para uploads que não passam pelos servidores de aplicação: um ticket que reserva cota e devolve uma URL assinada de envio, uma etapa de conclusão que verifica o objeto armazenado, um worker de varredura que o promove ou o apaga, regras de ciclo de vida para uploads abandonados e um modelo de status que explica cada objeto armazenado.
-
Passo a passo de um serviço de notificações: canais, preferências, tentativas de entrega e retentativas
Roteiro de projeto para um serviço de notificações multicanal: API de ingestão com chave de idempotência, roteador que expande cada notificação em entregas por canal após verificar as preferências, filas e políticas de retentativa por canal, tratamento de callbacks para tokens inválidos e o que deixar para depois.
-
Serviços de links curtos com identificadores sequenciais recebem mais requisições de enumeração do que serviços com identificadores aleatórios
Hipótese: num encurtador de URLs cujas chaves são um contador codificado em base62, qualquer pessoa consegue percorrer todos os links, enquanto chaves aleatórias de comprimento fixo fazem a maioria das tentativas falhar. Propõe-se que os serviços sequenciais recebam uma fatia maior de requisições a chaves existentes vindas de clientes que nunca receberam o link, e que a taxa de respostas 404 não distinga os dois tipos.
-
Passo a passo de um encurtador de URLs: geração de chaves, status de redirecionamento e controles contra abuso
Um roteiro de projeto para um encurtador de URLs: chaves aleatórias em base62 com nova tentativa em caso de colisão, um caminho de redirecionamento que usa um cache e um armazenamento, 302 em vez de 301 quando os destinos precisam ser revogáveis e contabilizáveis, verificações de abuso na criação e uma lista do que não construir primeiro.
-
Roteiro de um agendador de jobs: leases, retentativas, chaves de idempotência e uma tabela de fila
Roteiro de projeto para jobs em segundo plano e agendamentos recorrentes sobre uma tabela de banco de dados: workers reivindicam linhas com FOR UPDATE SKIP LOCKED sob um lease, falhas são reagendadas com backoff até um máximo, uma chave de idempotência única transforma enfileiramentos duplicados em operações nulas, e um message broker só entra quando a idade da fila indicar essa necessidade.
-
Roteiro de busca em um corpus de documentos: pipeline de indexação, permissões e reindexação
Roteiro de projeto para busca em documentos mantidos em um sistema de registro: índice derivado e reconstruível, alimentado por eventos de mudança, chaves de ACL indexadas como campos para filtrar antes do ranking, índices versionados trocados por alias, um reconciliador que detecta divergências e uma lista do que adiar.
-
Passo a passo de um leaderboard: eventos de pontuação, um sorted set derivado e rankings reconstruíveis
Guia de projeto para leaderboards: eventos de pontuação autoritativos no servidor, com chave de idempotência, como fonte da verdade; um sorted set por período de ranking como índice derivado para consultas de top-N e de posição individual; regras de desempate codificadas na pontuação; fronteiras de período definidas pelo momento de ocorrência; e reconstruções como rotina.
-
Quando as equipes trocam uma tabela de fila no PostgreSQL por um message broker, e o que motivou a mudança?
Pergunta em aberto: a documentação do PostgreSQL admite SKIP LOCKED para vários consumidores em uma tabela usada como fila, e guias de design recomendam começar por ela; quais gatilhos (idade da fila, contenção de locks, bloat da tabela, necessidade de fan-out, carga operacional) levaram de fato à troca por um broker, em que volumes, e quantos sistemas nunca trocaram?
-
Guia do armazenamento de sessões: ids opacos, duas expirações, revogação e comportamento em caso de indisponibilidade
Guia de projeto para o armazenamento no servidor por trás de um cookie de sessão: linhas indexadas pelo hash do id, expiração por inatividade e absoluta como configuração, gravações de last-seen com limitação, índice por usuário para encerrar sessões em todos os lugares, comportamento fail-closed quando o armazenamento fica indisponível e funcionalidades a adiar.
-
Passo a passo de um serviço de feature flags: rulesets, avaliação local e rollouts percentuais estáveis
Um passo a passo de design para um serviço de flags: definições servidas como um ruleset versionado por ambiente, SDKs que fazem cache e avaliam localmente, um contexto de avaliação para segmentação, bucketing por hash estável para que os usuários nunca alternem de variante durante um rollout, valores pré-avaliados para clientes não confiáveis e relatórios que identificam flags mortas.
-
Passo a passo de um serviço de configuração: versões imutáveis, rollout em etapas e última versão válida conhecida
Um roteiro de design para distribuir configuração em tempo de execução: versões imutáveis e validadas; um controlador de rollout que move coortes escolhidas por um hash estável por etapas, com tempo de espera e condição de parada; clientes que fazem polling ou watch, aplicam de forma atômica e mantêm um arquivo de última versão válida conhecida (last-known-good); e o que fica deliberadamente de fora.
-
Guia de design de um sistema de comentários: threads, estados de moderação e conteúdo re-renderizável
Um guia de design para comentários em threads com moderação: o texto-fonte é a fonte da verdade e é renderizado na leitura por um sanitizador atualizado, com caminho materializado e limite de profundidade, estados pending/visible/hidden/removed que preservam a estrutura da thread, auditoria de denúncias e ações de moderação, e funcionalidades deixadas deliberadamente para depois.
Legível por máquina: JSON