Em um mercado dinâmico como o hoteleiro, tomar decisões com agilidade e precisão é vital. No entanto, a realidade de muitas empresas inclui diversas aplicações legadas, dados espalhados em múltiplos bancos e dificuldade em criar uma visão consolidada.
Foi exatamente esse o cenário de um dos nossos clientes: uma rede hoteleira que precisava de um dashboard centralizado, rápido e atualizado em tempo real, sem sobrecarregar os sistemas que sustentavam suas operações.
Neste artigo, mostramos como a GOW resolveu esse desafio com uma arquitetura moderna baseada em Data Lake, CDC, Event-Driven Architecture e CQRS — entregando uma solução robusta com tempo de renderização inferior a 0,5 segundos.
O desafio: dados dispersos, decisões lentas
O cliente possuía múltiplos sistemas e bancos de dados, utilizados em áreas como reservas, check-in, gestão de quartos, faturamento e CRM.
Cada sistema funcionava bem isoladamente, mas a ausência de integração dificultava a geração de insights em tempo real. O time de gestão precisava de um dashboard único com:
- Visualização unificada de dados operacionais
- Atualizações em tempo quase real
- Desempenho alto mesmo com grandes volumes de dados
- Zero impacto nos sistemas legados
A solução GOW: Data Lake, eventos e CQRS na prática
Para resolver esse cenário, adotamos uma abordagem que respeitasse os sistemas existentes, sem criar dependências diretas, e ao mesmo tempo construísse uma base sólida para escalabilidade futura.
🔹 1. Criação de um Data Lake centralizado em PostgreSQL
Optamos por implementar o Data Lake diretamente em uma instância dedicada de Amazon Aurora PostgreSQL (modo serverless para escalabilidade automática).
Além disso, aplicamos o padrão CQRS (Command Query Responsibility Segregation), separando leitura e escrita. Com isso:
- Pudemos remover diversos índices de leitura nos bancos legados, otimizando significativamente operações de
INSERTeUPDATE. - As consultas analíticas e pesadas foram movidas para o Data Lake, isolando a carga.
🔹 2. Implementação de CDC (Change Data Capture)
Utilizamos o AWS DMS (Database Migration Service) para capturar alterações em tempo real nos bancos existentes, sem afetar os sistemas de origem.
🔹 3. Orquestração com arquitetura orientada a eventos
Cada evento de alteração de dados era publicado em uma fila SQS. Um conjunto de AWS Lambdas monitorava essas filas, acionando pipelines ETL serverless que processavam, limpavam e padronizavam os dados automaticamente.
Tolerância a falhas
- Dead-letter queue no SQS para eventos DMS que não puderam ser aplicados.
- Retries automatizados com backoff exponencial, configurado no próprio DMS.
🔹 4. Observalibidade completa
A camada de visualização, totalmente desacoplada, foi construída com Grafana, permitindo dashboards rápidos, flexíveis e altamente visuais.
- Logs estruturados
- Cada Lambda envia logs JSON para CloudWatch Logs, incluindo campos:
request_idevent_sourcerecords_processederror_code/error_message
- Cada Lambda envia logs JSON para CloudWatch Logs, incluindo campos:
- Métricas customizadas
- CloudWatch Metrics:
- Latência de ingestão (tempo entre chegada na SQS- e insert).
- Contagem de mensagens com falha vs. sucesso.
- Dashboards no Grafana (via datasource CloudWatch + Aurora PostgreSQL):
- Gráfico de throughput de eventos (events/sec).
- Heatmap de latência de consultas.
- Painel de erros da DLQ.
- CloudWatch Metrics:
- Alertas e SLAs
- Alarmes CloudWatch:
- Ingestão parada (>5 min sem eventos).
- Erro alto (≥ 5% de mensagens na DLQ em 10 min).
- Notificações via SNS → Slack / e-mail.
- Alarmes CloudWatch:
Diagrama de Arquitetura Transformamos cada alteração de dados capturada pelo CDC num evento autônomo, permitindo escalabilidade, tolerância a falhas e processamento em lote
