Categoria
Em sistemas distribuídos, a comunicação assíncrona entre serviços é essencial para escalabilidade e desacoplamento. No entanto, essa abordagem introduz um desafio crítico: como garantir que uma mensagem recebida seja processada exatamente uma vez, mesmo diante de falhas de rede, reinicializações de serviços ou concorrência?
O padrão read model estabelece uma separação clara entre o modelo de escrita (command model) e o modelo de leitura (read model). Enquanto o command model é otimizado para validação de regras de negócio e persistência de eventos, o read model é construído especificamente para atender consultas de forma eficiente. Essa separação permite que cada lado evolua independentemente, com esquemas e tecnologias de armazenamento diferentes.
No Domain-Driven Design, o agregado é uma unidade de consistência transacional. Isso significa que todas as operações que modificam o estado interno de um agregado devem ser atômicas — ou tudo é salvo, ou nada é salvo. A fronteira do agregado define exatamente quais objetos compartilham essa garantia.
Eventos de domínio representam fatos consumados que ocorreram dentro de um contexto delimitado (bounded context). No design orientado a eventos, eles são a espinha dorsal da comunicação entre agregados e sistemas, registrando mudanças de estado que importam para o negócio.
O processamento assíncrono com filas é um padrão arquitetural fundamental para sistemas distribuídos modernos. Diferentemente do processamento síncrono, onde o solicitante aguarda a conclusão da operação, o modelo assíncrono introduz um intermediário — a fila — que desacopla produtores e consumidores.
Auditoria, rastreabilidade e logging são conceitos frequentemente confundidos, mas possuem propósitos distintos. Logging refere-se ao registro genérico de eventos do sistema para diagnóstico. Rastreabilidade é a capacidade de seguir o ciclo de vida completo de uma transação ou dado. Auditoria é o processo formal de verificação de conformidade, exigindo registros imutáveis e não-repudiáveis.
Em sistemas distribuídos, inconsistências surgem principalmente por três fatores: latência de rede (mensagens atrasadas ou reordenadas), falhas parciais (nós que falham sem completar operações) e concorrência (atualizações simultâneas em réplicas diferentes). Essas condições fazem com que réplicas do mesmo dado apresentem estados divergentes.
Sistemas de scheduling distribuído coordenam a execução de tarefas em múltiplos nós de um cluster. Quando introduzimos liderança eleitoral, um nó é eleito líder para coordenar a distribuição e o monitoramento de jobs, enquanto os demais atuam como workers. O líder é responsável por manter o estado global do sistema, tomar decisões de agendamento e garantir que cada tarefa seja executada exatamente uma vez.
Processos longos são workflows cuja execução se estende por horas, dias ou até semanas, diferindo fundamentalmente de transações curtas e síncronas. Enquanto um workflow síncrono é concluído em milissegundos dentro de uma única requisição HTTP, processos longos exigem persistência de estado, tolerância a falhas e capacidade de retomada.
Sistemas tolerantes a falhas são projetados para continuar operando corretamente mesmo quando componentes individuais falham. O princípio fundamental é que falhas são inevitáveis em sistemas distribuídos — servidores crasham, discos corrompem, redes particionam. A tolerância a falhas não elimina falhas, mas as gerencia de forma previsível.