iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
É possível ampliar a capacidade de um sistema legado sem substituí-lo por inteiro: identifique uma capacidade de negócio que precise evoluir, construa a funcionalidade nova ao lado do sistema atual e migre em etapas. Use o padrão strangler fig quando puder redirecionar funções gradualmente para componentes novos; use leave-and-layer quando a prioridade for manter o legado intacto. Introduza eventos apenas onde desacoplamento ou escala independente tragam valor — e trate duplicatas, atrasos e consistência eventual como parte do projeto, não como detalhes posteriores.
Comece pelo gargalo e pela capacidade de negócio
“Escalar” pode significar atender mais carga, processar trabalho com mais rapidez ou permitir que uma parte do produto evolua sem arriscar o restante. Arquitetura orientada a eventos (EDA) pode ajudar a separar produtores de consumidores e permitir que esses componentes processem e escalem de forma independente. Ela não corrige automaticamente um banco de dados saturado, uma consulta ineficiente ou um gargalo que continue concentrado no legado. O resultado depende do ambiente e da carga; não há um ganho percentual ou desempenho superior garantido.
Antes de escolher tecnologia, mapeie os processos e as capacidades de negócio envolvidos. Identifique onde a capacidade está limitada, quais mudanças são necessárias e quais sistemas dependem dos dados ou do comportamento em questão. A orientação da AWS para modernizar monólitos recomenda decompor o trabalho em etapas e estabelecer objetivos para a transição, em vez de tratar a substituição total como ponto de partida: Ten steps to modernizing legacy monoliths in the AWS Cloud.
Escolha uma fatia pequena o bastante para limitar o risco, mas relevante o bastante para testar uma hipótese real: por exemplo, se uma capacidade pode ser executada fora do monólito ou se determinado consumidor precisa acompanhar o volume de trabalho de forma independente. Defina como reconhecer o sucesso — como cumprir um requisito de negócio ou aliviar o gargalo identificado — sem presumir que adotar microsserviços, um broker ou processamento assíncrono seja o objetivo.
#1 Best Overall
Escolha como introduzir a funcionalidade nova
Os dois padrões abaixo permitem modernização incremental, mas resolvem problemas diferentes. O strangler fig encaminha funções aos poucos para o novo sistema; leave-and-layer acrescenta capacidades ao lado do legado sem exigir que ele seja alterado desde o início. A escolha depende do acesso ao código, do conhecimento do domínio, dos limites de integração e de quanto a equipe pode intervir com segurança.
| Critério | Strangler fig | Leave-and-layer |
|---|---|---|
| Mudança no legado | Funções são extraídas gradualmente e encaminhadas aos componentes novos. | O legado pode permanecer inalterado enquanto novas capacidades são adicionadas ao lado. |
| Quando tende a se ajustar | Quando a equipe consegue compreender e separar capacidades e controlar o encaminhamento entre sistemas. | Quando é importante limitar a intervenção no legado ou há pouco conhecimento do seu funcionamento interno. |
| Integração a planejar | Roteamento e migração de funções; dados compartilhados e transações entre componentes precisam de atenção. | Interfaces ou eventos para conectar o novo ao antigo; sincronização e conceitos ou estado duplicados podem se tornar riscos. |
| Destino possível | Partes são substituídas gradualmente; a aposentadoria do legado pode ser um objetivo, não uma exigência inicial. | As novas capacidades ampliam o sistema; o legado não precisa necessariamente ser substituído. |
Essas distinções são descritas nas orientações da AWS sobre o padrão strangler fig e o padrão leave-and-layer. Nenhum deles elimina a necessidade de entender limites de domínio e dependências de dados; eles mudam onde e em que ritmo a equipe precisa atuar.
Planeje a migração em fatias controláveis
- Mapeie o fluxo de negócio e as dependências. Registre quem inicia o processo, quais componentes alteram ou leem os dados e quais consumidores precisam reagir. Procure descobrir se a capacidade está realmente isolada ou se o legado ainda controla etapas e estado indispensáveis.
- Escolha uma capacidade delimitada. Priorize uma necessidade que tenha valor claro e fronteiras compreensíveis. Considere dependências de dados, risco de mudança no legado e a capacidade da equipe de operar processamento assíncrono.
- Decida o limite entre o antigo e o novo. Para strangler fig, planeje quais funções serão desviadas e como o tráfego chegará ao componente novo. Para leave-and-layer, defina a interface ou os eventos que conectam a capacidade adicionada sem pressupor uma alteração no legado.
- Especifique o contrato de integração. Defina o significado dos eventos, quem os publica e quem os consome, além dos requisitos de ordem, atraso e repetição. Para integração síncrona, esclareça qual componente é responsável por cada operação e pelos dados correspondentes.
- Implemente e valide a fatia antes de ampliar a migração. Observe se o comportamento atende ao objetivo definido e se a integração funciona em falhas e reprocessamentos. Amplie o encaminhamento ou adicione consumidores somente quando a equipe puder operar a fatia com segurança.
- Revise o que ficou para trás. Acompanhe dependências, estado duplicado e funcionalidades ainda presas ao legado. Decida com base no objetivo original se a próxima etapa é extrair outra capacidade, manter os dois sistemas integrados ou planejar uma substituição mais ampla.
Use eventos quando o desacoplamento resolver um problema real
Em uma EDA, produtores geram eventos, consumidores reagem a eles e canais — muitas vezes brokers ou serviços de ingestão — fazem a transferência. Essa descrição corresponde à documentação do estilo de arquitetura orientada a eventos da Microsoft. O produtor não precisa chamar cada consumidor diretamente, o que pode facilitar a integração de vários subsistemas e o escalonamento independente de consumidores.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Eventos são especialmente úteis quando vários sistemas precisam reagir à mesma mudança, quando o processamento pode ocorrer de forma assíncrona ou quando consumidores têm necessidades de capacidade diferentes. Por exemplo, um produtor pode emitir um evento de negócio para que mais de um consumidor realize tarefas distintas, sem incorporar essas tarefas ao fluxo principal do legado. O exemplo só é apropriado se os consumidores puderem lidar com os atrasos e as falhas próprios do processamento assíncrono.
Rank #3
Um evento comunica que algo aconteceu; ele não equivale, por si só, a um pedido que precisa de resposta imediata. Se a operação depende de confirmação síncrona ou da leitura imediata de um estado único e atualizado, a espera por consumidores assíncronos pode não atender ao requisito. Não acrescente broker e fluxo assíncrono a um pedido-resposta simples que já satisfaz os requisitos de latência e capacidade. Quando o negócio não tolera que sistemas apresentem estados diferentes por algum tempo, trate explicitamente essa exigência antes de escolher EDA para a transação.
Evite a gravação dupla com outbox ou CDC
Uma aplicação que grava uma alteração no banco e publica uma mensagem em uma operação separada corre o risco de concluir apenas metade do trabalho: o estado pode ser salvo sem evento, ou o evento pode ser publicado sem que a alteração correspondente tenha sido confirmada. Essa falha de gravação dupla deixa o legado e seus consumidores com visões divergentes.
Rank #4
Com o padrão outbox, a aplicação grava a alteração de negócio e o registro do evento na mesma transação do banco. Um processo separado lê os registros pendentes e publica as mensagens. A publicação continua sujeita a repetição ou atraso, por isso a outbox não significa entrega única nem consistência global automática. A orientação da AWS sobre transactional outbox descreve esse padrão e suas considerações.
Change data capture (CDC) pode ser uma alternativa: em vez de inserir um evento em uma tabela outbox, captura mudanças no banco e as encaminha ao fluxo de eventos. A adequação depende do banco, do formato de mudança disponível e dos controles operacionais para capturar e processar essas alterações. A abordagem também aparece na orientação da AWS sobre consistência de domínio em arquiteturas orientadas a eventos, no contexto de manter sistemas legados e microsserviços alinhados durante uma modernização. Nem CDC nem outbox prometem consistência global ou entrega exatamente uma vez em qualquer broker.
| Abordagem | Como o evento chega ao fluxo | O que avaliar |
|---|---|---|
| Outbox transacional | A aplicação grava a mudança de negócio e a linha de evento na mesma transação; outro processo publica o evento. | Leitura e publicação dos registros, duplicatas, atrasos, reprocessamento e ordem quando exigida pelo domínio. |
| CDC | Um mecanismo captura mudanças no banco e as encaminha ao fluxo. | Compatibilidade do banco, formato das mudanças e capacidade de operar a captura e o processamento. |
Projete consumidores para repetição, atraso e falha
Na prática, consumidores precisam tolerar mensagens repetidas: uma falha ou uma repetição de publicação pode fazer o mesmo evento chegar mais de uma vez. O consumidor deve ser idempotente — processar de novo um evento sem aplicar indevidamente a mesma alteração duas vezes. Também é necessário decidir em quais fluxos a ordem é relevante; não imponha uma garantia de ordem universal se apenas determinados processos de domínio dependem dela.
- Defina o tratamento de duplicatas: determine como o consumidor reconhece ou neutraliza o processamento repetido.
- Defina a ordem necessária: identifique por entidade ou processo quais eventos precisam ser aplicados numa sequência e como lidar com uma sequência quebrada.
- Planeje falhas e reprocessamento: estabeleça como mensagens que não puderam ser tratadas serão identificadas, corrigidas e processadas novamente.
- Monitore a integração: acompanhe atrasos, falhas de publicação e consumo e crescimento de trabalho pendente para perceber divergências antes que virem problemas de negócio.
- Explicite a consistência visível ao usuário: deixe claro quais leituras podem refletir um estado anterior enquanto outros componentes ainda processam o evento.
Esses controles não são extras opcionais: EDA distribui o trabalho entre produtores e consumidores e torna o comportamento diante de atrasos e falhas parte da arquitetura. A escolha por eventos deve levar em conta a maturidade operacional da equipe, não apenas a possibilidade técnica de publicar uma mensagem.
Como decidir se a arquitetura está ajudando
Uma integração nova vale a pena quando remove ou reduz um gargalo identificado, permite que uma capacidade evolua com menor risco ou atende uma necessidade real de processamento independente. Observe o fluxo de negócio e os limites de operação definidos para a fatia: se atrasos, divergências temporárias ou esforço de suporte tornam o processo inaceitável, a integração precisa ser revista. Se não há consumidores independentes nem necessidade de desacoplamento, uma interface direta pode ser mais simples.
O objetivo não é converter o monólito inteiro em microsserviços ou introduzir eventos em toda comunicação. É preservar a continuidade do sistema enquanto partes específicas são estendidas ou substituídas, com limites claros e confiabilidade adequada ao comportamento assíncrono. O padrão escolhido deve acompanhar as restrições reais: a disponibilidade de código e conhecimento do domínio, as dependências de dados e a tolerância do negócio a estados temporariamente divergentes.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
