Escolha de arquitetura para integração de sistemas com restrição de latência e legado
Uma rede de clínicas precisa integrar o prontuário eletrônico (novo, baseado em microsserviços) ao sistema de faturamento de convênios (legado, monolítico, com banco Oracle e API SOAP instável). O volume é de 3.000 atendimentos/dia, com picos de 400 requisições por minuto no início da manhã. O faturamento não pode perder eventos: cada atendimento concluído deve gerar uma cobrança. A API SOAP do legado tem tempo de resposta médio de 2 segundos e falha em cerca de 5% das chamadas em horário de pico. A equipe propõe chamadas síncronas diretas do prontuário para o faturamento. O prazo para entrada em produção é de 90 dias e não há verba para substituir o legado.
1. Avalie a proposta de integração síncrona direta e indique se ela atende aos requisitos de confiabilidade e desempenho.
Read the worked answer
Não atende.
- Confiabilidade: com 5% de falha no pico e chamada síncrona, o prontuário ficaria dependente da disponibilidade do legado; perda de evento significa cobrança não gerada (impacto financeiro direto).
- Desempenho: 2 s por chamada, com 400 req/min (~6,7 req/s), exigiria concorrência alta e criaria filas; uma indisponibilidade do legado bloquearia o fluxo clínico.
- Acoplamento: o prontuário herdaria a fragilidade do monolito, contrariando a proposta de microsserviços.
Conclusão: a integração síncrona direta viola o requisito de não perder eventos e expõe o atendimento a falhas do faturamento.
2. Proponha uma alternativa arquitetural compatível com o prazo de 90 dias e explique como ela trata falhas e picos.
Read the worked answer
Alternativa: integração assíncrona orientada a eventos com fila durável.
- O prontuário publica um evento
AtendimentoConcluidoem uma fila (ex.: RabbitMQ/Kafka) ao finalizar o atendimento; a operação clínica não espera o faturamento. - Um serviço adaptador consome a fila e traduz para SOAP, com retry exponencial e dead-letter queue para falhas persistentes.
- Idempotência por identificador de atendimento evita cobrança duplicada em reprocessamentos.
- A fila absorve picos (400 req/min) como buffer, desacoplando a taxa de chegada da capacidade do legado.
Tratamento de falhas: mensagens não confirmadas permanecem na fila; após esgotar tentativas, vão para DLQ com alerta e reprocessamento manual. Prazo: viável em 90 dias, pois o legado é mantido e o esforço concentra-se no adaptador e na fila. Complementarmente, monitorar latência e taxa de DLQ.