Documentação da Arquitetura — Solução CPTM

1. Objetivo

O redesenho do aplicativo da CPTM tem como objetivo central oferecer uma experiência de usuário fluida, moderna e confiável. A proposta envolve a definição de uma nova arquitetura, capaz de sustentar o crescimento da aplicação e suportar a introdução contínua de novas funcionalidades, além do desenvolvimento de APIs robustas para integração com sistemas internos e serviços externos como status das linhas e bicletários. Um dos pilares dessa nova solução é a escalabilidade, fundamental para garantir a estabilidade do sistema em momentos críticos — como greves, enchentes ou falhas na malha ferroviária — que geram picos de acesso e grande carga nos serviços. Assim, a arquitetura proposta combina modularidade, resiliência e observabilidade para assegurar que o app evolua de forma sustentável e eficiente, acompanhando as necessidades da operação e dos passageiros.

2. Visão Geral do App

2.1 Principais razões da reformulação do app

Performance do APP

• Picos inesperados (atrasos por trem de carga, greves, enchentes) geram alta simultaneidade de acessos, deixando o app lento ou indisponível.
• Usuário navegando em várias abas simultaneamente pode sobrecarregar o frontend e o backend.

Tecnologia legada

• Código antigo dificulta deploy de correções e rollout de novas funcionalidades.

2.2 Funcionalidades Principais

Para visualizar as principais funcionalidades, é recomendado ver o documento de requisitos. No documento são descritas todas as funcionalidades esperadas dentro da aplicação.

3. Avaliação de Escalabilidade

Aspecto	Desafio	Mitigação Proposta
Picos de Acesso	Sobrecarga de requisições em eventos críticos (greves, enchentes)	- API Gateway com rate-limiting e circuit breaker - Auto-scale de serviços baseados em métricas de QPS
Latência Simultânea	Frontend multipage concorrente causa gargalos no backend	- Serviços stateless, escalonamento horizontal - Cache distribuído (Redis) para consultas frequentes
Legado vs. Evolução	Código antigo impede deploy contínuo e incorpora dívidas técnicas	- Modularização em microsserviços desacoplados - CI/CD com pipelines independentes por serviço
Integrações Terceiros	Queda ou lentidão de serviços de SOS/Train afetando UX	- Service proxies com timeouts e fallbacks - Estratégia de circuit breaker
Processos Assíncronos	Processos de volumetria e notificações podem atrasar resposta ao usuário	- Message Queue (event-driven) para workloads assíncronos - Orchestrator dedicado a fluxos longos

4. Arquitetura da Solução

A arquitetura foi desenhada com foco em escalabilidade, desacoplamento, observabilidade e facilidade de manutenção. Um ponto importante de destacar, é que a arquitetura foi idealizada sem a definição das tecnologias, visto que o mais importante no momento é garantir o fluxo da aplicação. Isso permite com que seja algo desaclopável e modular, podendo substituir tech stacks facilmente, evitando o problema enfrentado pela CPTM. Os principais componentes são:

4.1 Descrição da arquitetura

Frontend

• Mobile App: único ponto de acesso para o usuário. Realiza chamadas à API Gateway para todas as operações.

Backend

• API Gateway: centraliza e roteia as requisições para os serviços corretos, aplicando políticas de segurança e roteamento.

• Auth Service: realiza autenticação e autorização dos usuários.

• User Data Service: gerencia o cadastro e preferências do usuário.

• Bicletário Service Proxy: interface intermediária entre a aplicação e o serviço externo de bicicletários.

• Train Service Proxy: interface intermediária entre a aplicação e o serviço de status de trens.

• Orchestrator: coordena operações de negócio complexas, como notificações ou regras inteligentes baseadas nos dados do usuário.

• Internal Database: base de dados relacional ou NoSQL para persistência de dados do usuário e sessões.

• Monitoring & Logs: capta e centraliza logs, métricas e alertas do sistema.

5. Fluxos Críticos e Escalonamento

1. Consulta de Próximo Trem

   • Fluxo síncrono: Mobile → API Gateway → Train Service Proxy → Train Service
   • Caching de previsões por linha (TTL curtíssimo) para aliviar o backend em picos

2. Registro de Trajeto e Favoritos

   • Fluxo síncrono para gravação: Mobile → API Gateway → User Data Service → Internal DB
   • Fluxo assíncrono para histórico/análise: User Data Service → Orchestrator → Message Queue → processamento posterior

3. Notificações Push

   • Eventos de incidente capturados pelo Orchestrator, enfileirados e processados por workers independentes
   • Escalonamento horizontal dos workers conforme backlog da fila

6. Considerações Finais

• Escalabilidade horizontal garantida pelos serviços stateless e auto-scaling.
• Resiliência via circuit breakers e fallbacks nas integrações externas.
• Evolutividade e menor acoplamento com microsserviços modulares e pipelines de CI/CD independentes.
• Observabilidade centralizada (logs, métricas, tracing) para diagnóstico e otimização contínua.