Categoria
O padrão CQRS (Command Query Responsibility Segregation) propõe a separação explícita entre operações que modificam o estado do sistema (Commands) e operações que apenas leem dados (Queries). Em vez de usar um único modelo de dados para leitura e escrita, como ocorre em arquiteturas tradicionais, o CQRS sugere modelos distintos e otimizados para cada finalidade.
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.
Na arquitetura orientada a eventos (EDA), a comunicação entre microsserviços ocorre por meio de eventos — registros imutáveis que descrevem algo que aconteceu no sistema. Um produtor publica eventos em um barramento (message broker), sem conhecer quem irá consumi-los. Os consumidores se inscrevem para receber eventos relevantes e reagem de forma assíncrona.
Em uma arquitetura baseada em Domain-Driven Design (DDD), um bounded context representa um limite explícito onde um modelo de domínio específico é aplicado. Cada contexto possui sua própria linguagem ubíqua, regras e responsabilidades, o que exige mecanismos de comunicação bem definidos para integração.
A arquitetura monolítica é a forma mais tradicional de construir software: toda a aplicação é um único processo, com um único deploy e um único banco de dados compartilhado. Tudo está acoplado no mesmo artefato — um JAR, um executável ou uma imagem Docker monolítica.
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?
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.
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.
A arquitetura multi-tenant é um padrão de design onde uma única instância de aplicação atende múltiplos clientes (tenants), mantendo seus dados isolados. Existem três abordagens principais: database por tenant (isolamento máximo, mas alto custo operacional), schema por tenant (isolamento moderado) e tabela compartilhada (eficiência de recursos, mas requer isolamento lógico).
Testes de contrato são uma abordagem de verificação de compatibilidade entre serviços que estabelecem um "acordo formal" sobre como dois serviços devem interagir. Diferentemente de testes de integração tradicionais, que exigem que ambos os serviços estejam em execução simultaneamente, os testes de contrato validam as expectativas de comunicação sem a necessidade de infraestrutura completa.