Avaliando se um provedor de dados esportivos poderia substituir outro. A matriz de capacidades publicada e a API de trial discordavam, então a análise foi reconstruída sobre sondagens contra o endpoint real. Sobre derivar seu consumo do código em vez da memória, citar evidência por veredito, e rotular um apêndice explicitamente como não comprovado.
Uma notificação de loja reentregue não pode duplicar uma compra. Verificações em nível de aplicação são necessárias e insuficientes — sob entrega concorrente a única coisa que se sustenta com confiança é uma constraint. Sobre escolher a chave, a correção que tivemos que fazer nela no meio da execução, e por que o critério nomeia o mecanismo de imposição em vez do resultado.
O monolito vinha armazenando toda notificação de loja crua por anos — 720.183 delas. Isso transformou uma reescrita de um exercício de fixtures num exercício de replay. Sobre reconhecer um corpus acidental, semear um banco efêmero para o harness nunca tocar dados vivos, e por que guardar o payload cru é a coisa mais barata que você já vai fazer.
App Store e Google Play fazem retry agressivamente quando você está lento, então um handler que escreve no Postgres antes de dar acknowledgement transforma uma query lenta numa tempestade de retentativas. Sobre separar durabilidade de processamento, o registro de decisão que tivemos que substituir ao descobrir o que "durável" precisava significar, e por que nada pode receber ack sem estar registrado.
Um harness de paridade reportando 100% de concordância não diz nada até você saber o que ele perguntou. Sobre transformar cobertura num portão em vez de uma estatística, declarar as lacunas em voz alta, e delimitar um replay ao núcleo determinístico para que a alegação publicada seja uma que você consiga defender.
Antes de o novo serviço responder a um único usuário, ele computou entitlement para toda compra que tínhamos e suas respostas foram comparadas offline contra as do monolito. Zero discordâncias. A engenharia está inteiramente no que "zero" exigiu: fixar o relógio, escrever a lógica duas vezes de propósito, e tornar toda discordância diagnosticável sem reexecutar.
Instrumentamos um novo serviço Go com OpenTelemetry no primeiro dia e o configuramos para não emitir nada, porque nenhum coletor havia sido escolhido. Sobre separar uma decisão de código de uma operacional, por que isso vence tanto "adicionar depois" quanto "escolher um backend agora", e as letras miúdas que tornam isso honesto.
O novo serviço lê o banco do serviço antigo durante a fase de shadow, o que o torna um risco a menos que a conexão seja restrita por construção. Sobre critérios de aceite formulados como capacidades que um serviço precisa não ter, por que readiness e liveness não devem concordar sobre o banco, e configuração que falha alto no startup.
Reversibilidade como critério de aceite em vez de um plano de rollback escrito na noite anterior. Sobre fasear uma extração para que cada passo possa ser desfeito, por que "a gente reverte o deploy" deixa de ser verdade no momento em que dados se movem, e o critério de que o que fica para trás precisa ser tão explícito quanto o que se move.
"Escalável e confiável" não é uma especificação — é um desejo com boa assessoria de imprensa. Sobre escrever uma arquitetura-alvo como mecanismos e orçamentos, exigir que todo design nomeie seus tradeoffs junto com suas fronteiras, e dar a todo modo de falha conhecido um sinal consultável antes de construir qualquer coisa.
A pergunta bloqueante de qualquer extração. Sobre enumerar todo serviço que toca um banco compartilhado com direção e evidência, descobrir quais entidades são chaveadas por um provedor externo — e por que uma chave de provedor único silenciosamente torna seu histórico dependente de um fornecedor que você talvez substitua.
Você não pode reconstruir um serviço até saber exatamente o que ele promete ao mundo externo. Sobre derivar essa lista do código em vez da memória — rotas REST, aplicações implantadas, canais de tempo real, disparos de notificação — e tornar o inventário um artefato que testes garantem, em vez de um documento que apodrece.
"Assinar é instável" era a premissa para extrair um serviço do nosso monolito. Antes de projetar qualquer coisa eu medi no log group de produção — e a falha não era instabilidade alguma. Era uma máquina de estados rejeitando compras que deveria ter aceitado, 3.995 vezes em sete dias, atrás de um único código de erro opaco.
O primeiro capítulo da segunda edição de Designing Data-Intensive Applications não é sobre técnicas — é sobre trade-offs. Lendo-o à luz de cinco decisões reais de backend em uma plataforma esportiva: monolito vs distribuído, banco compartilhado vs banco por serviço, system of record vs dados derivados, cloud vs self-hosting, e minimização de dados como decisão de responsabilidade.
Quando múltiplos microsserviços compartilham um único banco PostgreSQL, migrations de schema viram um problema de coordenação. Veja como lidamos com isso no R10 com Django, Go e zero downtime.
Como eliminamos o intermediário Python adicionando endpoints REST diretamente a um microsserviço Go existente — reutilizando sua camada de serviços, repositórios e padrões assíncronos — enquanto o monólito continuava servindo mais de 100 endpoints.
Conectando os conceitos de stream processing do Designing Data-Intensive Applications — event streams, fan-out, backpressure, materialized views e semântica exactly-once — às decisões arquiteturais reais em um sistema de notificações esportivas em tempo real construído com Go, gRPC e AWS SNS.
Como eu construi o gowm, um window manager X11 tiling minimalista do zero usando Go
Construir um serviço de push notifications que lida com milhões de eventos de forma confiável requer decisões arquiteturais cuidadosas. Neste post, vou mostrar como construí um backend de notificações em Go que processa eventos via gRPC e entrega push notifications através do AWS SNS.
Um mergulho profundo em reescrever um backend de notificações Python asyncio em Go, alcançando 5x de melhoria em throughput, deduplicação distribuída adequada e imagem Docker 10x menor.
Um guia prático para implementar Event Sourcing e CQRS em Go, com um exemplo completo de domínio bancário incluindo agregados, projeções e snapshots.
Parte 1 da série 'Construindo um MMORPG'
O que os tutoriais não contam sobre consistência eventual, debug de estado distribuído e a complexidade operacional que vem com a separação de leituras e escritas.
Entendendo os padrões CQRS e Event Sourcing e como implementá-los em Go para sistemas escaláveis e auditáveis.
Entendendo e prevenindo race conditions em aplicações Go event-driven, com exemplos práticos e soluções.