ADR 0001 - Visão de Arquitetura
Introdução ao documento
Este ADR registra uma decisão arquitetural relevante e suas consequências.
Versionamento
- Versão do documento: 1.0.0
- Última atualização: 2026-03-09
- Responsável: Marivaldo Vinicius
Referencial teórico
-
Status: Aceito
-
Data: 2026-03-09
Contexto
Necessidade de construir um dashboard administrativo para agência de cursos (Dhedalos) que consolide dados de múltiplas fontes (Redshift, WordPress, AoVivo API) e forneça interface administrativa moderna com análise de sentimento e relatórios de NPS.
Requisitos principais:
- Interface administrativa completa
- API REST para consumo de dados
- Integração com múltiplas fontes de dados externas
- Análise de sentimento de textos
- Performance otimizada para grandes volumes de dados
- Controle de acesso baseado em roles
Decisão
1. Stack Principal: Laravel 11 + React/TypeScript
Utilizar Laravel 11 como backend e React/TypeScript como frontend, separando responsabilidades entre API REST e interface administrativa.
Justificativa:
- Laravel oferece ecossistema maduro para APIs e painéis administrativos
- React permite interface moderna e reativa
- TypeScript adiciona segurança de tipos no frontend
- Separação clara entre backend e frontend facilita manutenção
2. Painel Administrativo: Backpack for Laravel
Utilizar Backpack for Laravel como framework de painel administrativo em vez de construir interface do zero.
Justificativa:
- Acelera desenvolvimento de CRUDs e interfaces administrativas
- Integração nativa com Laravel e Spatie Permissions
- Interface moderna e responsiva (Tabler theme)
- Reduz código boilerplate para operações administrativas
3. Autenticação: Laravel Sanctum + Spatie Permissions
Utilizar Laravel Sanctum para autenticação de API e Spatie Permissions para controle de acesso baseado em roles.
Justificativa:
- Sanctum é nativo do Laravel, sem dependências externas complexas
- Suporta autenticação stateful (sessões) e stateless (tokens)
- Spatie Permissions oferece sistema robusto de roles e permissões
- Integração nativa com Backpack
4. Estrutura de Backend: API REST + Admin Controllers
Separar controllers em duas camadas: API REST (v1) para consumo de dados e Admin Controllers para interface administrativa.
Justificativa:
- Separação clara de responsabilidades
- API pode ser consumida por múltiplos clientes (frontend React, integrações)
- Admin Controllers focados em renderização de views
- Facilita versionamento da API
5. Cache Estratégico com Compressão
Implementar sistema de cache com compressão gzip para dados grandes (inscrições, agendamentos) e TTL variável baseado na criticidade dos dados.
Justificativa:
- Redshift tem latência alta, cache reduz consultas diretas
- Compressão gzip reduz uso de memória e transferência de dados
- TTL variável (30s a 4h) balanceia frescor e performance
- Jobs assíncronos atualizam cache sem bloquear requisições
6. Processamento Assíncrono: Laravel Queue + Supervisor
Utilizar Laravel Queue para processamento assíncrono de cache e Supervisor para gerenciar múltiplos workers.
Justificativa:
- Processamento de cache pode ser demorado, não deve bloquear requisições
- Supervisor garante alta disponibilidade dos workers
- Múltiplos processos (4 workers) aumentam throughput
- Timeout configurável (900s) para jobs longos
7. Integração com IA: Google Gemini API
Utilizar Google Gemini API para análise de sentimento em vez de modelos locais ou outras APIs.
Justificativa:
- Gemini oferece modelo generativo de alta qualidade
- API simples de integrar via pacote Laravel oficial
- Cache de resultados reduz custos e latência
- Flexibilidade para ajustar prompts conforme necessário
8. Servidor de Produção: FrankenPHP/Octane
Utilizar Laravel Octane com FrankenPHP em produção para melhor performance.
Justificativa:
- Octane mantém aplicação em memória, reduzindo overhead
- FrankenPHP oferece melhor performance que PHP-FPM tradicional
- Suporta aplicações de alta concorrência
- Compatível com workers assíncronos
Consequências
Positivas
- Desenvolvimento rápido: Backpack acelera criação de interfaces administrativas
- Performance: Cache e compressão otimizam resposta para grandes volumes de dados
- Escalabilidade: Processamento assíncrono permite lidar com cargas altas
- Manutenibilidade: Separação clara de responsabilidades facilita manutenção
- Flexibilidade: API REST permite múltiplos consumidores
- Segurança: Sanctum + Spatie oferecem controle de acesso robusto
Negativas
- Complexidade: Múltiplas camadas (API, Admin, Jobs, Services) aumentam complexidade
- Dependências: Backpack requer licença comercial para recursos avançados
- Cache stale: Dados podem estar desatualizados dependendo do TTL
- Custo de integrações: APIs externas (Gemini, AoVivo) têm custos associados
- Overhead de compressão: CPU adicional para compressão/descompressão
- Gestão de workers: Supervisor adiciona camada de gerenciamento
Alternativas consideradas
Backend puro vs Backpack
Alternativa: Construir painel administrativo do zero com Laravel + Blade/React Rejeitada porque: Desenvolvimento muito mais lento, necessidade de implementar CRUDs, autenticação e permissões manualmente
Redis Cache vs Laravel Cache
Alternativa: Usar Redis diretamente em vez de abstração Laravel Cache Rejeitada porque: Laravel Cache oferece flexibilidade (Redis/Memcached/File) e abstração consistente
Síncrono vs Assíncrono para Cache
Alternativa: Atualizar cache de forma síncrona nas requisições Rejeitada porque: Bloqueia requisições, especialmente para grandes volumes de dados do Redshift
Modelo de IA local vs API
Alternativa: Usar modelo de IA local ou outras APIs (OpenAI) Rejeitada porque: Gemini oferece boa relação custo-benefício e integração simples