Visão Geral do Sistema

1. Visão Geral

O sistema MRI (Motor de Regras de Insumos) é uma plataforma distribuída, desenhada para processar grandes volumes de payloads JSON de forma assíncrona, resiliente e escalável. A arquitetura utiliza o padrão Saga Orchestration para gerenciar workflows complexos e o Claim Check Pattern para manipulação de grandes volumes de dados.

2. Fluxo de Operação (Architecture Scorecard)

O diagrama abaixo ilustra o ciclo de vida de uma requisição, desde o recebimento via API Gateway até a notificação final ao cliente.

Architecture Scorecard

graph TD %% Entry Point Client[Client Application] -->|POST /inbound| Inbound[MRI Insumos Inbound] %% Persistence & Ingestion Inbound -->|Persiste Metadados| DB_Insumos[(DynamoDB: Insumos)] Inbound -->|Enfileira| SQS_Inbound[SQS: Inbound Queue] %% Orchestration SQS_Inbound --> Orchestrator[MRI Orchestrator] Orchestrator -->|Registra Estado| DB_Controle[(DynamoDB: Rota Controle)] %% Workers Orchestrator -->|Despacha Tarefa| SQS_Workers[SQS: Worker Queues] subgraph Workers_Group [MRI Consumers / Workers] Worker[Worker: OCR / Integrador] Worker -->|Se Payload > 400KB| S3[(Amazon S3: Claim Check)] Worker -->|Posta Resultado| SQS_Results[SQS: Result Queue] end %% Result Loop SQS_Results --> Orchestrator %% Finalization Orchestrator -->|Workflow Done| EventBridge[Amazon EventBridge] EventBridge --> Callback[MRI Callback Notifier] Callback -->|POST Webhook| Client

---

3. Solução de Persistência (Inbound)

Para o serviço de Inbound, adotamos o MongoDB devido à flexibilidade de schema e maior limite de tamanho de documento (BSON Limit: 16MB), simplificando a arquitetura inicial.

• Coleção input_requests (InputRequest): Armazena o payload JSON recebido e metadados (notificationParams).

  • PK: requestId
  • Schema: Flexível (Map<String, Object>).

• Coleção saga_controls (SagaControl): Gerencia o estado da Saga.

  • PK: requestId
  • Atributos: status, steps (lista de objetos com output), version (Optimistic Locking).

• Claim Check Pattern (Híbrido):

  • Embora o MongoDB suporte até 16MB, para payloads extremamente grandes, ainda utilizaremos o padrão Claim Check salvando o conteúdo no S3 e mantendo apenas a referência (s3Key) no documento MongoDB.

---

4. Componentes do Sistema

Componente	Responsabilidade	Tecnologia
Insumos Inbound	Gateway de entrada, validação de Schema e persistência inicial.	AWS Lambda / App Runner
Orchestrator	Gestão de estado da Saga, controle de retentativas e lógica de decisão.	AWS Step Functions ou Lambda
Consumers (Workers)	Execução de tarefas específicas (Ex: OCR, Validações).	ECS Fargate / Lambda
Callback Notifier	Notificação assíncrona via Webhook com Exponential Backoff.	AWS Lambda + SQS FIFO

---

5. Resiliência e Observabilidade

• Dead Letter Queues (DLQ): Toda fila SQS possui uma DLQ. Mensagens que falham após X tentativas são movidas para análise, evitando o bloqueio do processamento (Poison Pill).
• Retries: O Callback Notifier implementa Exponential Backoff para lidar com quedas nos servidores dos clientes.
• Tracing: Utilização de correlation-id em todos os logs e no cabeçalho das mensagens SQS para rastreio fim-a-fim via AWS X-Ray.

---

6. Exemplos de Payload

A. Entrada (Inbound)

{
  "clientId": "777",
  "data": { "documentType": "CNH", "imageRaw": "..." }
}

B. Resultado de Processamento (Worker para Orchestrator)

{
  "requestId": "uuid-123",
  "status": "SUCCESS",
  "claimCheck": "s3://mri-bucket/results/uuid-123.json",
  "isLargePayload": true
}

C. Notificação Final (Webhook)

{
  "status": "COMPLETED",
  "requestId": "uuid-123",
  "downloadUrl": "https://s3.amazonaws.com/.../result?token=..."
}