Documentação técnica • Autor: Leonardo Norbiato - Equipe de Engenharia
Cliente: Aster Technology / UVA
Última Atualização: 15/09/2025
Autores: Leonardo Norbiato - Equipe de Engenharia
1. OBJETIVO
Este documento consolida as informações técnicas e de arquitetura do projeto "microservice-events", um microserviço desenvolvido em Go responsável pelo gerenciamento de eventos, disparo de notificações e execução de tasks (esteira de endpoints). O serviço utiliza DynamoDB para armazenar eventos e notificações, Redis para tasks, e oferece integração com SQS, SMTP, Resend e Slack.
2. ÚLTIMA REVISÃO
- 15/09/2025 - Revisão e atualização da documentação (Equipe)
3. TECNOLOGIAS UTILIZADAS
- Backend
- Go 1.23.0, Gorilla Mux v1.8.1 (HTTP framework), AWS SDK v2 (DynamoDB, SQS)
- Redis (go-redis/v9.7.1), MongoDB Driver v1.17.3, Swagger (swaggo v1.16.4)
- Resend API (resend-go/v2.15.0), SMTP, Slack Webhooks
- UUID (google/uuid v1.6.0), Environment (joho/godotenv v1.5.1)
- Repositórios: GitHub (aster-technology/microservice-events)
- Frontend
- Não aplicável (API pura)
- Banco de Dados
- DynamoDB (eventos e notificações), Redis (tasks e cache)
- MongoDB (preparado, mas não utilizado atualmente)
- Ferramentas de Conexão e Infraestrutura
- Docker Compose (Redis + App), AWS DynamoDB, AWS SQS
- SMTP/Resend para envio de emails, Slack para notificações
4. FUNCIONALIDADES E DOMÍNIOS
Gerenciamento de Eventos:
- Criação de eventos com tipos configuráveis (ALERT, DANGER, etc.)
- Armazenamento no DynamoDB com chave composta (TenantID, UserID_TS)
- Regras condicionais: ALERT envia notificação Slack, DANGER envia email
- Listagem de todos os eventos com paginação (page, limit)
- Campos: ID, UserID, MicroserviceOrigin, Title, Description, Type, CreatedAt, UpdatedAt
- Suporte a ReturnedError, TriggerPayload, FilePath
Sistema de Notificações:
- Criação de notificações com status inicial "pending"
- Armazenamento no DynamoDB com chave composta (TenantID, UserID_TS)
- Publicação em fila (SQS ou local) para processamento assíncrono
- Consumer que envia email e atualiza status para "sent" ou "error"
- Suporte a múltiplos provedores de email (SMTP, Resend, Noop)
- Campos: TenantID, UserID, ToEmail, Subject, Body, Status, CreatedAt, UpdatedAt
- Fallback automático: Resend > SMTP > Noop (sem envio)
Tasks (Esteira de Endpoints):
- Criação de tasks com lista de endpoints para executar em sequência
- Ação final que pode usar dados dos endpoints anteriores
- Processamento assíncrono via canal local
- Status: pending, running, done, error
- Interpolação de URLs e campos dinâmicos via FieldMapping
- Armazenamento no Redis para processamento rápido
- Suporte a headers customizados e body dinâmico
- Progress tracking e error handling detalhado
- Multi-tenancy via header x-tenant-id
Integrações:
- Slack: Notificações para webhook configurado (eventos ALERT)
- Email: SMTP tradicional ou Resend API (eventos DANGER)
- AWS SQS: Fila de mensagens (opcional, fallback para fila local)
- DynamoDB: Armazenamento persistente (eventos, notificações, tasks)
- Redis: Cache e processamento de tasks
- MongoDB: Preparado mas não utilizado atualmente
Observabilidade:
- Swagger para documentação automática da API (/swagger/index.html)
- Logs estruturados com informações detalhadas
- Health checks via endpoint raiz (/)
- Métricas de performance das tasks
- Documentação interativa com exemplos de uso
- Suporte a OpenAPI 3.0 (swagger.json, swagger.yaml)
5. ARQUITETURA FRONTEND
Não aplicável - API pura sem frontend próprio
6. ARQUITETURA BACKEND
- Controllers/Handlers
- EventHandler: Criação e listagem de eventos
- NotificationHandler: Criação e listagem de notificações
- TaskHandler: Criação e consulta de tasks (esteira de endpoints)
- Features (Projeto)
- Gerenciamento de eventos com tipos (ALERT, DANGER, etc.)
- Sistema de notificações assíncronas via fila (SQS ou local)
- Tasks com execução sequencial de endpoints e ação final
- Integração com Slack para alertas
- Envio de emails via SMTP ou Resend
- Suporte a multi-tenancy
- Use Cases
- EventUseCase: Criação de eventos com regras condicionais
- NotificationUseCase: Criação e processamento de notificações
- TaskUseCase: Criação e execução de tasks com endpoints
- Repositories
- EventRepositoryDynamo: Persistência de eventos no DynamoDB
- NotificationRepositoryDynamo: Persistência de notificações no DynamoDB
- TaskRepositoryDynamo: Persistência de tasks no DynamoDB
- Entities
- Event: Entidade de evento (ID, UserID, Type, Title, Description, etc.)
- Notification: Entidade de notificação (TenantID, UserID, ToEmail, Subject, Body, Status)
- Task: Entidade de task (ID, TenantID, Endpoints, Action, Status)
- Helper/Utilities
- EmailService: Interface para envio de emails (SMTP, Resend, Noop)
- SlackService: Envio de notificações para Slack
- QueuePublisher: Interface para publicação em filas (SQS, Local)
- TaskQueuePublisher: Interface específica para tasks
7. ROTAS E ENDPOINTS
Rotas de Eventos:
- POST /events - Criar evento
- GET /events - Listar eventos
Rotas de Notificações:
- POST /notifications - Criar notificação
- GET /notifications - Listar notificações
Rotas de Tasks:
- POST /tasks - Criar task (esteira de endpoints)
- GET /tasks/{id} - Consultar status da task
Rotas de Sistema:
- GET / - Health check
- GET /swagger/index.html - Documentação Swagger
Exemplos de Uso:
Criar Evento:
POST /events
{
"user_id": "user123",
"microservice_origin": "my-microservice",
"title": "Evento Exemplo",
"description": "Descrição do evento",
"type": "DANGER"
}
Criar Notificação:
POST /notifications
{
"tenant_id": "tenantA",
"user_id": "user123",
"to_email": "exemplo@dominio.com",
"subject": "Assunto de Teste",
"body": "Corpo da mensagem de notificação."
}
Criar Task:
POST /tasks
{
"endpoints": [
{
"url": "http://localhost:8090/notifications",
"method": "POST",
"headers": { "Content-Type": "application/json" },
"body": { "tenant_id": "tenantB", "user_id": "user456", ... }
}
],
"action": {
"url": "http://localhost:9000/final-endpoint",
"method": "POST",
"fields": [
{
"endpoint_index": 0,
"path": "user_id_ts",
"key": "notif_user_id_ts"
}
]
}
}
8. ESTRUTURA DE DADOS, TABELAS E VIEWS
DynamoDB Tables:
- events
- Partition Key: TenantID (MicroserviceOrigin)
- Sort Key: UserID_TS (UserID#Timestamp)
- Atributos: Type, Title, Description, ReturnedError, TriggerPayload, FilePath
- CreatedAt, UpdatedAt
- notifications
- Partition Key: TenantID
- Sort Key: UserID_TS (UserID#Timestamp)
- Atributos: ToEmail, Subject, Body, Status
- CreatedAt, UpdatedAt
- tasks
- Partition Key: TaskID (UUID)
- Atributos: TenantID, Endpoints (JSON), Action (JSON), Status (JSON)
- RawPayload, CreatedAt, UpdatedAt
Redis:
- Tasks em memória para processamento assíncrono
- Cache de dados temporários
9. CONFIGURAÇÃO E VARIÁVEIS DE AMBIENTE
- Arquivo principal
- docker-compose.yml
- Variáveis principais
- APP_PORT: 8090 (porta do serviço)
- REDIS_ADDR: redis:6379 (endereço do Redis)
- REDIS_PASS: "" (senha do Redis)
- SQS_QUEUE_URL: "" (URL da fila SQS - opcional)
- SQS_DISABLED: false (desabilitar SQS)
- SMTP_HOST: smtp.resend.com (servidor SMTP)
- SMTP_PORT: 587 (porta SMTP)
- SMTP_USER: resend (usuário SMTP)
- SMTP_PASS: re_773Hpnev_6dUV5G2Yo4E41gArscULLS2h (senha SMTP)
- SMTP_FROM: onboarding@resend.dev (email remetente)
- RESEND_API_KEY: re_773Hpnev_6dUV5G2Yo4E41gArscULLS2h (chave Resend)
- SLACK_WEBHOOK_URL: "" (webhook do Slack - opcional)
- MONGO_URI: mongodb://root:example@mongo:27017 (URI MongoDB - preparado)
- MONGO_DB_NAME: notification_event_db (nome do banco MongoDB)
- Configurações Docker
- Redis: porta 6379, container redis_container, imagem redis:alpine
- App: porta 8090, container notification_event_app_container, build local
- MongoDB: porta 27017, container mongo_container (comentado no docker-compose)
- Volumes: redis_data e mongo_data para persistência
- Dependências: app depende de mongo e redis
12. INTEGRAÇÕES EXTERNAS
- Slack
- Notificações para webhook configurado (eventos ALERT)
- Email
- SMTP tradicional ou Resend API (eventos DANGER)
- AWS SQS
- Fila de mensagens (opcional, fallback para fila local)
- DynamoDB
- Armazenamento persistente (eventos, notificações, tasks)
- Redis
- Cache e processamento de tasks
- MongoDB
- Preparado mas não utilizado atualmente
10. TREEVIEW DA ARQUITETURA
microservice-events/
├── cmd/
│ └── main.go # Ponto de entrada da aplicação
├── config/
│ └── config.go # Configuração da aplicação
├── domain/
│ ├── event/
│ │ └── event.go # Entidade Event
│ ├── notification/
│ │ └── notification.go # Entidade Notification
│ └── task/
│ └── task.go # Entidade Task e estruturas
├── infrastructure/
│ ├── cache/
│ │ ├── memory_redis.go # Cache em memória
│ │ └── redis_client.go # Cliente Redis
│ ├── messasing/
│ │ ├── email_service.go # Serviço de email
│ │ ├── local_publisher.go # Publisher local
│ │ ├── model.go # Modelos de mensagem
│ │ ├── noop_publisher.go # Publisher vazio
│ │ ├── resend_email_service.go # Serviço Resend
│ │ ├── slack_service.go # Serviço Slack
│ │ ├── sqs_publisher.go # Publisher SQS
│ │ ├── task_local_publisher.go # Publisher de tasks
│ │ └── task_publisher.go # Interface de publisher
│ └── repository/
│ ├── event_repository_dynamo.go # Repositório de eventos
│ ├── event_repository.go # Interface de eventos
│ ├── notification_repository_dynamo.go # Repositório de notificações
│ ├── notification_repository.go # Interface de notificações
│ ├── task_repository_dynamo.go # Repositório de tasks
│ └── task_repository.go # Interface de tasks
├── interfaces/
│ └── handlers/
│ ├── event_handler.go # Handler de eventos
│ ├── notification_handler.go # Handler de notificações
│ └── task_handler.go # Handler de tasks
├── messaging/
│ ├── local_consumer.go # Consumer local
│ ├── queue_consumer.go # Consumer de fila
│ └── task_local_consumer.go # Consumer de tasks
├── models/
│ ├── error.go # Modelos de erro
│ ├── event.go # Modelos de evento
│ └── notification.go # Modelos de notificação
├── usecase/
│ ├── event/
│ │ └── event_usecase.go # Caso de uso de eventos
│ ├── notification/
│ │ └── notification_usecase.go # Caso de uso de notificações
│ └── task/
│ └── task_usecase.go # Caso de uso de tasks
├── docs/
│ ├── docs.go # Documentação Swagger
│ ├── swagger.go # Configuração Swagger
│ ├── swagger.json # Especificação JSON
│ └── swagger.yaml # Especificação YAML
├── docker-compose.yml # Orquestração de serviços
├── Dockerfile # Build da aplicação
├── go.mod # Dependências Go
├── go.sum # Checksums das dependências
└── README.md # Documentação do projeto
11. INTEGRAÇÕES E DEPENDÊNCIAS
- Serviços externos
- AWS DynamoDB (armazenamento de eventos e notificações)
- AWS SQS (fila de mensagens - opcional)
- Redis (cache e processamento de tasks)
- SMTP/Resend (envio de emails)
- Slack (notificações de alerta)
- Dependências principais
- github.com/gorilla/mux v1.8.1 (framework HTTP)
- github.com/aws/aws-sdk-go-v2 v1.36.3 (SDK AWS)
- github.com/aws/aws-sdk-go-v2/service/dynamodb v1.42.3 (DynamoDB)
- github.com/aws/aws-sdk-go-v2/service/sqs v1.38.1 (SQS)
- github.com/redis/go-redis/v9 v9.7.1 (cliente Redis)
- github.com/resend/resend-go/v2 v2.15.0 (API Resend)
- go.mongodb.org/mongo-driver v1.17.3 (driver MongoDB)
- github.com/swaggo/swag v1.16.4 (geração Swagger)
- github.com/swaggo/http-swagger v1.3.4 (servir Swagger)
- github.com/google/uuid v1.6.0 (geração de UUIDs)
- github.com/joho/godotenv v1.5.1 (variáveis de ambiente)
13. CONTROLE DE VERSÃO
- Repositório: GitHub (aster-technology/microservice-events)
- Versionamento semântico recomendado
- Docker multi-stage build
- Docker Compose para desenvolvimento
- Documentação Swagger automática
14. SEGURANÇA E ACESSO
- Autenticação via headers (x-tenant-id para tasks)
- Validação de dados de entrada com JSON decoding
- Rate limiting preparado (não implementado)
- Logs estruturados para auditoria
- Suporte a multi-tenancy via TenantID
- Headers de segurança configurados
- SSL/TLS preparado (não implementado)
- Validação de payloads JSON obrigatória
- Error handling padronizado com códigos HTTP
15. CONSIDERAÇÕES FINAIS
O microservice-events é um microserviço robusto e bem estruturado em Go que implementa um sistema completo de gerenciamento de eventos, notificações e tasks. Oferece processamento assíncrono, integração com múltiplos provedores de email, notificações Slack e execução de esteiras de endpoints.
Principais pontos fortes:
- Arquitetura limpa com separação clara de responsabilidades
- Sistema de tasks flexível com interpolação dinâmica
- Suporte a múltiplos provedores de email
- Integração com Slack para alertas
- Processamento assíncrono eficiente
- Documentação automática via Swagger
- Suporte a multi-tenancy
O serviço está preparado para produção e integração com o ecossistema de microserviços Aster/UVA, fornecendo capacidades de eventos, notificações e automação para todos os outros serviços.