Capítulo 72 — Eventos e Tópicos de Mensageria

72.1 Objetivo do Capítulo

Este capítulo documenta de forma consolidada e de referência o catálogo completo de eventos de domínio, comandos assíncronos e trabalhos distribuídos da Plataforma de Relacionamento Digital com o Cidadão.

O Capítulo 13 — Arquitetura de Mensageria e RabbitMQ — estabelece a infraestrutura, as convenções, o envelope, a topologia de exchanges e as políticas de operação. Este capítulo não os repete: concentra-se exclusivamente no conteúdo que circula nessa infraestrutura — quais mensagens existem, quem as publica, quem as consome, qual a estrutura do payload e qual a semântica de cada evento.

O catálogo aqui documentado é o artefato de referência para:

• times de desenvolvimento que implementam produtores ou consumidores;
• equipes de operação que configuram filas, alertas e DLQs;
• o processo de evolução de contratos e versionamento de schemas;
• a rastreabilidade com os requisitos funcionais (Anexo III) e as capacidades (Anexo IV) do edital.

72.2 Premissas e Convenções

72.2.1 Convenções de Nomenclatura

A nomenclatura adotada neste catálogo é derivada diretamente das convenções definidas no Capítulo 13, seção 13.6.

Routing keys de eventos de domínio:

<domínio>.<evento>.<versão>

Exemplos:
  request.submitted.v1
  citizen.updated.v1
  appointment.cancelled.v1

Routing keys de comandos assíncronos:

<capacidade>.<ação>.<versão>

Exemplos:
  communication.send.v1
  integration.sei.register.v1
  ai.knowledge.index.v1

Routing keys de trabalhos distribuídos:

<domínio-técnico>.<ação>.<versão>

Exemplos:
  document.ocr.v1
  ai.embedding.generate.v1
  datalake.ingest.v1

72.2.2 Envelope Padrão

Todo evento e comando publicado no RabbitMQ carrega o envelope padronizado definido no Capítulo 13, seção 13.7. Os campos id, type, version, occurredAt, tenantId, correlationId, causationId e producer estão sempre presentes. Este catálogo documenta apenas o conteúdo do campo payload — específico de cada mensagem.

72.2.3 Versionamento de Contratos

Cada evento carrega sua versão no campo type (ex.: request.submitted.v1). Mudanças de payload que mantêm compatibilidade retroativa não requerem nova versão major; mudanças incompatíveis (remoção de campo, alteração de tipo, mudança semântica) exigem v2 com coexistência temporária de versões, conforme a política de Schema Registry descrita no Capítulo 23, seção 23.6.

72.2.4 Isolamento Multi-Tenant

O campo tenantId no envelope garante isolamento em toda a cadeia assíncrona. Consumidores validam o tenantId antes de processar qualquer mensagem. Mensagens sem tenantId válido são rejeitadas sem processamento.

72.2.5 Semântica de Entrega

A semântica adotada é at-least-once. Todos os consumidores críticos implementam idempotência — seja por Inbox Pattern, seja por regra de negócio — conforme especificado no Capítulo 13, seção 13.13.

72.3 Exchanges de Referência

72.4 Catálogo de Eventos de Domínio

72.4.1 Domínio: Identity

Serviço produtor: Identity Service

Payload de referência — identity.user.created.v1:

{
  "userId": "uuid",
  "tenantId": "org-secretaria-educacao",
  "email": "usuario@email.gov.br",
  "userType": "CITIZEN",
  "createdAt": "2026-07-15T10:30:00.000Z",
  "channel": "WEB"
}

Consumidores típicos:

• Audit Service → registra criação na trilha de auditoria
• Communication Service → envia boas-vindas se configurado
• Analytics Service → atualiza projeção de base de usuários do tenant

72.4.2 Domínio: Tenant

Serviço produtor: Tenant Service

Payload de referência — tenant.modules-changed.v1:

{
  "tenantId": "org-secretaria-saude",
  "previousModules": ["CRM", "BPM", "GED"],
  "currentModules": ["CRM", "BPM", "GED", "SCHEDULING"],
  "changedBy": "admin-uuid",
  "changedAt": "2026-07-15T14:00:00.000Z"
}

Consumidores típicos:

• Configuration Service → invalida cache de configuração do tenant
• Audit Service → registra mudança de módulos
• Analytics Service → ajusta projeções de capacidade

72.4.3 Domínio: Citizen

Serviço produtor: Citizen Service

Payload de referência — citizen.consent-changed.v1:

{
  "citizenId": "uuid",
  "tenantId": "org-detran",
  "previousConsents": {
    "marketing": true,
    "dataSharing": false
  },
  "currentConsents": {
    "marketing": false,
    "dataSharing": false
  },
  "changedAt": "2026-07-15T09:15:00.000Z",
  "channel": "MOBILE"
}

Consumidores típicos:

• Communication Service → respeita preferências na próxima comunicação
• Segmentation Service → reavalia inclusão em segmentos
• Data Lake Ingestion → ingere mudança de consentimento com timestamp

72.4.4 Domínio: Service Catalog

Serviço produtor: Service Catalog Service

Payload de referência — catalog.service.published.v1:

{
  "serviceId": "uuid",
  "tenantId": "org-fazenda",
  "serviceName": "Certidão de Débitos Fiscais",
  "category": "TRIBUTARIO",
  "channels": ["WEB", "MOBILE"],
  "hasScheduling": false,
  "hasWorkflow": true,
  "publishedAt": "2026-07-15T08:00:00.000Z"
}

Consumidores típicos:

• Analytics Service → indexa novo serviço em projeções de catálogo
• AI Builder → candidato a indexação na base de conhecimento RAG

72.4.5 Domínio: Forms

Serviço produtor: Forms Service

Payload de referência — form.version-published.v1:

{
  "formId": "uuid",
  "serviceId": "uuid",
  "tenantId": "org-sedu",
  "version": 5,
  "previousVersion": 4,
  "publishedAt": "2026-07-15T11:30:00.000Z",
  "effectiveFrom": "2026-07-16T00:00:00.000Z"
}

Consumidores típicos:

• Request Service → valida qual versão de formulário deve ser apresentada
• Audit Service → registra publicação de nova versão

72.4.6 Domínio: Request (Solicitações)

Serviço produtor: Request Service

Payload de referência — request.submitted.v1:

{
  "requestId": "uuid",
  "protocolNumber": "2026-SEDU-00012345",
  "serviceId": "uuid",
  "citizenId": "uuid",
  "formId": "uuid",
  "formVersion": 5,
  "channel": "WEB",
  "documentIds": ["doc-uuid-1", "doc-uuid-2"],
  "submittedAt": "2026-07-15T10:30:00.000Z"
}

Payload de referência — request.status-changed.v1:

{
  "requestId": "uuid",
  "protocolNumber": "2026-SEDU-00012345",
  "previousStatus": "SUBMITTED",
  "currentStatus": "IN_ANALYSIS",
  "changedBy": "analyst-uuid",
  "changedAt": "2026-07-15T14:00:00.000Z",
  "reason": null
}

Consumidores típicos para request.submitted.v1:

• Workflow Service → inicia instância de processo BPM
• Communication Service → envia confirmação com protocolo ao cidadão
• Analytics Service → atualiza projeção de solicitações do tenant
• Data Lake Ingestion → ingere evento na partição do tenant

72.4.7 Domínio: Workflow

Serviço produtor: Workflow Service

Payload de referência — workflow.instance-started.v1:

{
  "instanceId": "uuid",
  "processDefinitionId": "uuid",
  "processDefinitionVersion": 3,
  "requestId": "uuid",
  "tenantId": "org-sedu",
  "startedAt": "2026-07-15T10:31:05.000Z",
  "triggeredBy": "request.submitted.v1",
  "causationId": "evt-request-uuid"
}

Consumidores típicos:

• Task Service → cria tarefas conforme etapas do processo
• Analytics Service → monitora SLAs e gargalos de processo
• Audit Service → registra progressão do processo

72.4.8 Domínio: Task

Serviço produtor: Task Service

Payload de referência — task.sla-breached.v1:

{
  "taskId": "uuid",
  "instanceId": "uuid",
  "requestId": "uuid",
  "tenantId": "org-sedu",
  "assignedTo": "analyst-uuid",
  "slaDeadline": "2026-07-15T17:00:00.000Z",
  "breachedAt": "2026-07-15T17:00:05.000Z",
  "hoursOverdue": 0.001
}

Consumidores típicos para task.sla-warning.v1 e task.sla-breached.v1:

• Communication Service → notifica analista, supervisor e gestor
• Analytics Service → incrementa indicadores de violação de SLA
• Workflow Service → avalia acionamento de escalada automática

72.4.9 Domínio: CRM

Serviço produtor: CRM Service

Payload de referência — crm.human-assistance-requested.v1:

{
  "interactionId": "uuid",
  "citizenId": "uuid",
  "tenantId": "org-detran",
  "channel": "CHAT",
  "aiSessionId": "uuid",
  "transferReason": "COMPLEXITY",
  "context": {
    "topicIdentified": "habilitacao-renovacao",
    "messageCount": 5,
    "lastIntentConfidence": 0.43
  },
  "requestedAt": "2026-07-15T11:20:00.000Z"
}

Consumidores típicos:

• Communication Service → notifica atendente disponível
• Analytics Service → registra taxa de transferência para humano
• Audit Service → registra sessão de IA e desfecho

72.4.10 Domínio: Communication

Serviço produtor: Communication Service

Payload de referência — communication.delivered.v1:

{
  "messageId": "uuid",
  "citizenId": "uuid",
  "tenantId": "org-sedu",
  "channel": "EMAIL",
  "templateId": "tmpl-confirmacao-solicitacao",
  "correlationId": "corr-xyz",
  "deliveredAt": "2026-07-15T10:31:30.000Z",
  "providerMessageId": "ext-id-do-provedor"
}

Consumidores típicos:

• Analytics Service → atualiza métricas de entrega por canal e template
• Data Lake Ingestion → ingere evento para análise de engajamento

72.4.11 Domínio: Document

Serviço produtor: Document Service

Payload de referência — document.uploaded.v1:

{
  "documentId": "uuid",
  "citizenId": "uuid",
  "tenantId": "org-fazenda",
  "fileName": "comprovante-residencia.pdf",
  "mimeType": "application/pdf",
  "sizeBytes": 245760,
  "sha256": "a1b2c3d4e5f6...",
  "documentType": "COMPROVANTE_RESIDENCIA",
  "sourceRequestId": "uuid",
  "uploadedAt": "2026-07-15T10:29:50.000Z"
}

Consumidores típicos para document.uploaded.v1:

• OCR Worker → extrai texto do documento
• Metadata Worker → extrai metadados estruturados
• AI Builder → gera embeddings para RAG (se autorizado por política)
• Audit Service → registra recebimento do documento

72.4.12 Domínio: Scheduling (Agendamentos)

Serviço produtor: Scheduling Service

Payload de referência — appointment.scheduled.v1:

{
  "appointmentId": "uuid",
  "citizenId": "uuid",
  "tenantId": "org-detran",
  "serviceId": "uuid",
  "agendaId": "uuid",
  "unitId": "uuid",
  "slotId": "uuid",
  "scheduledDate": "2026-07-22",
  "scheduledTime": "14:30",
  "protocolNumber": "AGD-2026-0001234",
  "confirmedAt": "2026-07-15T10:30:00.000Z"
}

Consumidores típicos:

• Communication Service → envia confirmação com protocolo e detalhes
• Analytics Service → atualiza taxa de ocupação de agendas
• Data Lake Ingestion → ingere evento na partição do tenant

72.4.13 Domínio: Ombudsman (Ouvidoria)

Serviço produtor: Ombudsman Service

Payload de referência — ombudsman.manifestation-created.v1:

{
  "manifestationId": "uuid",
  "tenantId": "org-saude",
  "type": "RECLAMACAO",
  "protocolNumber": "OUV-2026-00005678",
  "isAnonymous": false,
  "citizenId": "uuid",
  "subject": "Demora no agendamento de consulta especializada",
  "registeredAt": "2026-07-15T09:00:00.000Z",
  "deadlineAt": "2026-08-14T23:59:59.000Z"
}

Consumidores típicos:

• Communication Service → envia protocolo ao cidadão (se não anônimo)
• Workflow Service → inicia processo de tratamento de manifestação
• Integration Service → aciona sincronização com MG-Ouv quando configurado

72.4.14 Domínio: Satisfaction

Serviço produtor: Satisfaction Service

Payload de referência — satisfaction.feedback-received.v1:

{
  "feedbackId": "uuid",
  "citizenId": "uuid",
  "tenantId": "org-detran",
  "serviceId": "uuid",
  "requestId": "uuid",
  "channel": "MOBILE",
  "score": 4,
  "scaleMax": 5,
  "comment": "Atendimento rápido, mas a interface poderia ser mais clara.",
  "receivedAt": "2026-07-15T15:45:00.000Z"
}

Consumidores típicos:

• Analytics Service → consolida indicadores de satisfação por serviço e canal
• Data Lake Ingestion → ingere avaliação para análise histórica

72.4.15 Domínio: Segmentation

Serviço produtor: Segmentation Service

Payload de referência — segment.calculated.v1:

{
  "segmentId": "uuid",
  "tenantId": "org-fazenda",
  "segmentName": "Contribuintes com débito em 2026",
  "audienceSize": 4523,
  "calculatedAt": "2026-07-15T03:00:00.000Z",
  "criteria": {
    "type": "BEHAVIORAL",
    "summary": "Cidadãos com débito tributário registrado em 2026"
  }
}

Consumidores típicos:

• Campaign Service → habilita uso do segmento em campanhas ativas

72.4.16 Domínio: Campaign

Serviço produtor: Campaign Service

Payload de referência — campaign.completed.v1:

{
  "campaignId": "uuid",
  "tenantId": "org-fazenda",
  "segmentId": "uuid",
  "channel": "EMAIL",
  "totalTargeted": 4523,
  "totalSent": 4521,
  "totalFailed": 2,
  "startedAt": "2026-07-15T08:00:00.000Z",
  "completedAt": "2026-07-15T08:14:22.000Z"
}

Consumidores típicos:

• Analytics Service → consolida métricas de campanha
• Communication Service → correlaciona entregas com campanha para rastreamento

72.4.17 Domínio: Data Quality

Serviço produtor: Data Quality Service

Payload de referência — data-quality.issue-detected.v1:

{
  "issueId": "uuid",
  "tenantId": "org-sedu",
  "datasetId": "requests",
  "ruleId": "rule-tenant-id-not-null",
  "severity": "ERROR",
  "affectedRecords": 3,
  "detectedAt": "2026-07-15T04:30:00.000Z",
  "dimension": "COMPLETUDE"
}

Consumidores típicos:

• Analytics Service → exibe alerta no painel de qualidade de dados
• Audit Service → registra incidente de qualidade

72.4.18 Domínio: Integration

Serviço produtor: Integration Service

Payload de referência — integration.sei.registered.v1:

{
  "integrationId": "uuid",
  "tenantId": "org-saude",
  "externalSystem": "SEI_MG",
  "operation": "REGISTER_PROCESS",
  "requestId": "uuid",
  "externalId": "SEI-2026-0001234",
  "registeredAt": "2026-07-15T10:32:00.000Z"
}

Consumidores típicos:

• Request Service → associa referência SEI à solicitação
• Audit Service → registra integração governamental

72.4.19 Domínio: AI

Serviço produtor: AI Gateway / AI Builder

Payload de referência — ai.chat-completed.v1:

{
  "sessionId": "uuid",
  "citizenId": "uuid",
  "tenantId": "org-detran",
  "channel": "MOBILE",
  "messageCount": 8,
  "durationSeconds": 142,
  "resolvedByAi": true,
  "transferredToHuman": false,
  "topicClassification": "habilitacao-renovacao",
  "modelUsed": "claude-sonnet",
  "endedAt": "2026-07-15T11:22:00.000Z"
}

Consumidores típicos:

• Analytics Service → consolida métricas de uso de IA por tenant
• Data Lake Ingestion → ingere sessão para análise de comportamento
• Satisfaction Service → aciona coleta de feedback pós-sessão se configurado

72.5 Catálogo de Comandos Assíncronos

Comandos assíncronos representam solicitações explícitas de execução. Circulam pela exchange platform.commands (tipo direct) e são processados por um único consumidor lógico.

Payload de referência — communication.send.v1:

{
  "communicationId": "uuid",
  "citizenId": "uuid",
  "tenantId": "org-detran",
  "channel": "EMAIL",
  "templateId": "tmpl-confirmacao-agendamento",
  "variables": {
    "nomeServico": "Renovação de CNH",
    "dataAgendamento": "2026-07-22",
    "horaAgendamento": "14:30",
    "protocolo": "AGD-2026-0001234",
    "unidade": "DETRAN-BH-CENTRO"
  },
  "priority": "NORMAL",
  "requestedAt": "2026-07-15T10:30:05.000Z"
}

Payload de referência — integration.sei.register.v1:

{
  "commandId": "uuid",
  "requestId": "uuid",
  "tenantId": "org-saude",
  "seiUnit": "SAÚDE-PROTO-001",
  "processType": "ATENDIMENTO-CIDADAO",
  "description": "Solicitação de agendamento especializado",
  "documentIds": ["doc-uuid-1"],
  "requester": {
    "name": "João Silva",
    "cpf": "***"
  },
  "requestedAt": "2026-07-15T10:30:02.000Z"
}

Nota de segurança: Dados pessoais sensíveis como CPF completo não devem ser transmitidos em payload de mensagem. A referência ao citizenId é suficiente; o Integration Service recupera os dados necessários do serviço de identidade no momento da chamada, respeitando o princípio de minimização de dados em trânsito.

72.6 Catálogo de Trabalhos Distribuídos

Trabalhos distribuídos escalam horizontalmente por workers competidores. Circulam pela exchange platform.work (tipo direct).

Payload de referência — ai.embedding.generate.v1:

{
  "jobId": "uuid",
  "tenantId": "org-sedu",
  "knowledgeBaseId": "uuid",
  "sourceType": "DOCUMENT",
  "sourceId": "doc-uuid",
  "chunkCount": 12,
  "model": "multilingual-e5-large",
  "requestedAt": "2026-07-15T10:30:10.000Z"
}

72.7 Mapeamento de Filas por Consumidor

Esta seção mapeia os eventos mais relevantes para as filas de consumidores correspondentes. O padrão de nomenclatura segue <consumidor>.<propósito> conforme o Capítulo 13, seção 13.6.

Para o evento request.submitted.v1

Para o evento document.uploaded.v1

Para o evento task.sla-breached.v1

Para o evento tenant.modules-changed.v1

72.8 Dead Letter Queues por Domínio

Cada consumidor possui sua DLQ própria, com nome derivado do nome da fila de trabalho. Nenhuma DLQ é global.

Cada DLQ tem owner definido, dashboard de monitoramento, alerta de volume e runbook de reprocessamento — conforme política operacional descrita no Capítulo 13, seção 13.17.

72.9 Política de Retenção e Versionamento de Eventos

72.9.1 Ciclo de Vida de uma Versão

72.9.2 Compatibilidade de Evolução

72.9.3 Coexistência de Versões

Durante migração de v1 para v2, o produtor publica nos dois routing keys por período definido. Consumidores migram individualmente e confirmam conclusão. O produtor descontinua v1 após todos os consumidores confirmarem migração.

72.10 Observabilidade do Catálogo de Mensagens

72.10.1 Métricas por Evento

Para cada routing key em produção, as seguintes métricas são emitidas:

• messages.published.total — contador de publicações por routing key e tenant
• messages.consumed.total — contador de consumos com status (success, error, retry)
• messages.processing.duration — histograma de tempo de processamento por consumidor
• messages.dlq.size — gauge de mensagens acumuladas em DLQ

72.10.2 Alertas Críticos

72.10.3 Rastreabilidade End-to-End

O correlationId propagado no envelope de cada mensagem permite rastrear toda a cadeia assíncrona desencadeada por uma única ação do cidadão — desde a submissão de uma solicitação até a confirmação de entrega da notificação, o registro no SEI!MG e a ingestão no Data Lake — como uma única trilha coerente no sistema de observabilidade.

72.11 Rastreabilidade com os Requisitos do Edital

Anexo III — Requisitos Funcionais

Anexo IV — Capacidades Técnicas

Anexo V — Sustentabilidade

72.12 Decisões Arquiteturais Relacionadas

72.13 Considerações Finais

Este catálogo documenta 65 tipos de mensagens distribuídos em 19 domínios da plataforma — eventos de domínio, comandos assíncronos e trabalhos distribuídos. Cada mensagem tem routing key versionada, produtor identificado, payload de referência, consumidores típicos e DLQ correspondente.

O catálogo é um artefato vivo: a incorporação de novos eventos segue o processo de Schema Registry (Capítulo 23), exige definição de owner, payload documentado, política de compatibilidade e registro na tabela de contratos. Nenhum evento é publicado em produção sem contrato aprovado.

A rastreabilidade assíncrona ponta a ponta — garantida pelo correlationId e causationId propagados em toda cadeia — torna este catálogo também o mapa de observabilidade da plataforma: cada operação do cidadão pode ser reconstruída como sequência de eventos correlacionados, desde a ação inicial até os efeitos em todos os domínios afetados.

O Capítulo 73 — Dicionário de Dados documenta as entidades de negócio, seus atributos e os relacionamentos entre os domínios da plataforma.

72.14 Controle de Versão

72.15 Rastreabilidade PRODEMGE

• [ANX-III] — Blocos 1 a 6: todos os grupos funcionais têm eventos documentados neste catálogo, cobrindo relacionamento, BPM, GED, dados/IA, integração e administração.
• [ANX-IV] — Capacidades de mensageria assíncrona, processamento paralelo, integração governamental e IA desacoplada evidenciadas no catálogo completo de routing keys e consumidores.
• [ANX-V] — Sustentabilidade: contratos versionados com política de compatibilidade, DLQs operacionalizadas, observabilidade end-to-end por correlationId, evolução incremental sem ruptura.
• [PNR] — Plano de Negócio Referencial: eventos de integração com SEI!MG e MG-Ouv documentados; Data Lake alimentado por eventos de todos os domínios; IA com processamentos não interativos desacoplados por filas.
• [EDITAL] — CP001/2026: plataforma distribuída, assíncrona, resiliente e rastreável com catálogo formal de contratos de mensagens.