Blog

Ver todos
Estratégias de retry com dead letter queue para dependências externas instáveis
Arquitetura de Software e Sistemas Distribuídos 05/05/2026

Estratégias de retry com dead letter queue para dependências externas instáveis

Dependências externas — APIs de terceiros, bancos de dados remotos, serviços de mensageria — falham de maneiras distintas. Falhas transientes (timeout, conexão recusada, throttling) são temporárias e podem ser resolvidas com repetição. Falhas permanentes (payload inválido, recurso inexistente, erro de autenticação) nunca terão sucesso, independentemente do número de tentativas. Ignorar essa distinção leva a desperdício de recursos e degradação do sistema.

Notícias

Todos Recentes Tendências
Event-driven architecture na prática: quando eventos resolvem e quando complicam

Arquitetura de Software e Sistemas Distribuídos

Event-driven architecture na prática: quando eventos resolvem e quando complicam

A arquitetura orientada a eventos (EDA) difere fundamentalmente do modelo tradicional request-response. Enquanto em sistemas REST um serviço A chama diretamente o serviço B e aguarda uma resposta síncrona, na EDA um produtor publica um evento em um barramento e segue seu fluxo — os consumidores interessados reagem de forma assíncrona.

05/05/2026

Revista

Ver todos
Estratégias de tag e release notes automáticas com release-please

Git e Controle de Versão

Estratégias de tag e release notes automáticas com release-please

O release-please é uma ferramenta open-source mantida pelo Google que automatiza todo o ciclo de versionamento e geração de release notes baseada em Conventional Commits. Diferente de ferramentas como semantic-release ou standard-version, o release-please opera gerando Pull Requests de release em vez de executar diretamente no pipeline de CI/CD. Isso oferece uma camada adicional de controle e revisão antes que uma nova versão seja efetivamente publicada.

Estratégias de priorização de backlog: RICE, ICE e MoSCoW na prática

Produto, Gestão, Times e Comunicação

Estratégias de priorização de backlog: RICE, ICE e MoSCoW na prática

Em times de produto, a fila de demandas cresce mais rápido que a capacidade de entrega. Sem critérios claros, o backlog vira um cemitério de ideias — e o time, uma vítima do “mais barulhento vence”. O custo da falta de critério é alto: retrabalho por funcionalidades mal planejadas, desperdício de recursos em itens de baixo valor e times frustrados por não verem impacto real no que fazem.