Disclaimer

Este texto foi inicialmente concebido pela IA Generativa em função da transcrição do episódio do nosso canal, Dev Eficiente.Como foi uma live, não conseguimos embedar o vídeo direto aqui no post. Para conferir, basta seguir este link.

Introdução

Sistemas distribuídos são complexos por natureza. Lidar com comunicação entre diferentes componentes, redes instáveis e erros inesperados exige um planejamento cuidadoso. Neste post, vamos explorar como garantir resiliência nesses sistemas utilizando três ideias: timeout, idempotência e o Outbox Pattern.

Timeout: Controlando Incertezas na Comunicação

Uma das primeiras preocupações em sistemas distribuídos é lidar com chamadas remotas que podem demorar ou até falhar. Estar em um estado de incerteza sobre o tempo que uma requisição pode levar é um grande risco. Por isso, definir um timeout para chamadas remotas é essencial.

Timeouts ajudam a estabelecer um limite de espera para o cliente, garantindo que o sistema não fique bloqueado indefinidamente. Sem essa definição, há o risco de sobrecarga e falhas em cascata. Sempre questione se o código ou as configurações de framework incluem um tempo limite para requisições. Se não, implemente.

Exemplo

Imagine que sua aplicação faz uma chamada HTTP para outro serviço e o tempo de resposta esperado não é claro. Um timeout bem configurado garante que, após um determinado período de espera, sua aplicação trate o problema de forma controlada, evitando estados de bloqueio.

Idempotência: Garantindo Consistência em Requisições Repetidas

Errores na rede são comuns, e políticas de retry muitas vezes tentam reprocessar requisições. No entanto, isso pode levar a problemas graves, como mensagens duplicadas ou estados inconsistentes. É aqui que entra a idempotência.

Idempotência garante que uma mesma operação executada múltiplas vezes produza o mesmo resultado. Isso é fundamental para sistemas que recebem chamadas duplicadas, como gateways de pagamento ou APIs de terceiros.

Práticas para Idempotência

• Utilize chaves únicas: Use uma chave idempotente para identificar requisições. Essa chave garante que, mesmo em caso de retries, o sistema reconheça que a requisição já foi processada.
• Designe o comportamento esperado: Certifique-se de que, ao receber uma segunda chamada para a mesma operação, o sistema responda consistentemente, seja com sucesso ou erro.

Exemplo

Imagine um usuário tentando comprar ingressos para um show e pressionando F5 várias vezes. Sem idempotência, ele poderia acabar comprando múltiplos ingressos ou, pior, ser cobrado mais de uma vez sem sucesso. Um sistema idempotente evita essas situações ao tratar requisições repetidas como uma única operação.

Outbox Pattern: Lidando com Dual Writes

Sistemas distribuídos muitas vezes precisam realizar operações em diferentes componentes, como gravar dados no banco e enviar mensagens para um broker. Isso pode levar ao problema de dual writes, onde uma operação é bem-sucedida e outra falha, deixando o sistema em um estado inconsistente.

O Outbox Pattern minimiza esse problema ao centralizar as operações em uma transação atômica. Em vez de tentar realizar múltiplas operações simultaneamente, o padrão utiliza uma tabela de saída no banco de dados. Primeiro, todos os dados são gravados de forma transacional, e um processo assíncrono lê os eventos da tabela e os envia para o destino final.

Exemplo

Imagine que você precisa gravar um pedido no banco e enviar uma mensagem para o Kafka. Com o Outbox Pattern, ambas as operações são registradas no banco de dados em uma única transação. Um job ou thread secundária envia os eventos ao Kafka de forma resiliente, minimizando a chance de ter parte operação não concluída.

Conclusão

Resiliência em sistemas distribuídos depende de práticas sólidas e planejamento cuidadoso. Timeout, idempotência e o Outbox Pattern formam uma combinação interessante para prevenir estados inconsistentes e garantir maior confiabilidade.

• Timeout evita bloqueios indeterminados.
• Idempotência garante consistência em requisições duplicadas.
• Outbox Pattern ataca o problema de escrita em múltiplos sistemas.

Implementar essas técnicas pode não apenas melhorar a estabilidade do seu sistema, mas também proporcionar uma experiência mais robusta para os usuários. Lembre-se: a chave para resiliência é conhecer os limites do seu sistema e projetar soluções que respeitem esses limites.