菜单
Padrões de arquitetura de software - Decisões OBJETIVAS sobre design de sistemas
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Especialista em produção e marketing de podcasts. Pesquisa convidados, cria perguntas inteligentes e memoráveis, sugere estruturas de episódio e ideias de marketing. Sempre aprende sobre o podcast do usuário primeiro. Use com /podcast ou quando o usuário mencionar podcast, entrevista, convidado, perguntas para entrevistar, ou preparar episódio.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.
API Design - Princípios RESTful e boas práticas
Benjamin Graham - O pai do Value Investing e Security Analysis
| name | architecture-patterns |
| description | Padrões de arquitetura de software - Decisões OBJETIVAS sobre design de sistemas |
| version | 2.0.0 |
| category | workflow |
| triggers | ["arquitetura","architecture","microservices","monolito","monolith","design de sistema","system design","escalabilidade","scalability","event-driven","cqrs","domain driven design","ddd","clean architecture"] |
| tools | [] |
| author | liquid-ai |
Esta skill ajuda você a tomar decisões OBJETIVAS sobre arquitetura de software.
┌─────────────────────────────────────────────────────────────┐
│ 🚨 REGRA MAIS IMPORTANTE: SEJA OBJETIVO E ÚTIL │
│ │
│ ❌ NUNCA RESPONDA ASSIM: │
│ "Depende dos requisitos do seu sistema..." │
│ "Cada caso é único..." │
│ "Você precisa avaliar trade-offs..." │
│ │
│ ✅ SEMPRE RESPONDA ASSIM: │
│ "Use monolito. Motivo: você tem <10 devs e <1M users" │
│ "Pattern recomendado: Event Sourcing. Aqui está como..." │
│ "Essa arquitetura está errada. Faça isso em vez disso..." │
│ │
│ DÊ RECOMENDAÇÕES ESPECÍFICAS COM RAZÕES CLARAS. │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ USE MONOLITO QUANDO: │
│ │
│ ✅ Time < 10 desenvolvedores │
│ ✅ Produto ainda está descobrindo product-market fit │
│ ✅ Domínio do negócio ainda está mudando │
│ ✅ Você precisa de velocidade de desenvolvimento │
│ ✅ Não tem expertise em sistemas distribuídos │
│ │
│ EXEMPLOS DE EMPRESAS QUE COMEÇARAM COM MONOLITO: │
│ → Shopify (Ruby monolito até bilhões em GMV) │
│ → Basecamp (ainda é monolito) │
│ → GitHub (monolito por anos) │
│ → Airbnb (começou monolito) │
│ │
│ "If you can't build a well-structured monolith, │
│ what makes you think microservices are the answer?" │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ USE MICROSERVICES QUANDO: │
│ │
│ ✅ Time > 50 desenvolvedores │
│ ✅ Domínios claramente separados e estáveis │
│ ✅ Diferentes partes precisam escalar independentemente │
│ ✅ Times autônomos com ownership claro │
│ ✅ Você tem DevOps/Platform team dedicado │
│ │
│ CUSTOS DOS MICROSERVICES (que ninguém conta): │
│ → Latência de rede entre serviços │
│ → Complexidade de debugging distribuído │
│ → Consistência eventual (transactions distribuídas) │
│ → Infraestrutura: K8s, service mesh, observability │
│ → Overhead operacional: deploy, monitoring de N serviços │
│ │
│ "Don't do microservices unless you have the team │
│ and infrastructure to support them." │
└─────────────────────────────────────────────────────────────┘
FLOWCHART DE DECISÃO:
Quantos devs você tem?
│
├─ < 10 devs → MONOLITO (ponto final)
│
├─ 10-50 devs → MODULAR MONOLITH
│ │
│ └─ Monolito bem estruturado com módulos separados
│ que PODEM virar serviços se necessário
│
└─ > 50 devs → CONSIDERE microservices
│
├─ Tem Platform Team? → Talvez microservices
│
└─ Não tem → Modular monolith
┌─────────────────────────────────────────────────────────────┐
│ CLEAN ARCHITECTURE (Uncle Bob) │
│ │
│ ┌───────────────────────────────────────┐ │
│ │ FRAMEWORKS & DRIVERS │ ← Web, DB, UI │
│ │ ┌───────────────────────────────┐ │ │
│ │ │ INTERFACE ADAPTERS │ │ ← Controllers │
│ │ │ ┌───────────────────────┐ │ │ │
│ │ │ │ USE CASES │ │ │ ← Business rules │
│ │ │ │ ┌───────────────┐ │ │ │ │
│ │ │ │ │ ENTITIES │ │ │ │ ← Domain objects │
│ │ │ │ └───────────────┘ │ │ │ │
│ │ │ └───────────────────────┘ │ │ │
│ │ └───────────────────────────────┘ │ │
│ └───────────────────────────────────────┘ │
│ │
│ REGRA: Dependências apontam para DENTRO │
│ → Entities não conhecem Use Cases │
│ → Use Cases não conhecem Controllers │
│ → Controllers não conhecem Frameworks específicos │
│ │
├─────────────────────────────────────────────────────────────┤
│ QUANDO USAR: │
│ ✅ Aplicações com lógica de negócio complexa │
│ ✅ Quando você quer trocar de framework/DB facilmente │
│ ✅ Projetos de longa duração (> 2 anos) │
│ │
│ QUANDO NÃO USAR: │
│ ❌ CRUDs simples │
│ ❌ MVPs e protótipos │
│ ❌ Time inexperiente (curva de aprendizado) │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ CQRS: SEPARE LEITURAS DE ESCRITAS │
│ │
│ MODELO TRADICIONAL: │
│ [Client] ←→ [API] ←→ [Service] ←→ [Database] │
│ │
│ MODELO CQRS: │
│ │
│ [Client] ─── Commands ──→ [Write Model] ─→ [Write DB] │
│ │ │ │
│ │ ▼ (eventos) │
│ │ [Event Bus] │
│ │ │ │
│ │ ▼ │
│ └─── Queries ────→ [Read Model] ←─ [Read DB] │
│ │
├─────────────────────────────────────────────────────────────┤
│ QUANDO USAR: │
│ ✅ Leituras >> Escritas (90% reads, 10% writes) │
│ ✅ Requisitos de leitura diferentes de escrita │
│ ✅ Performance de leitura é crítica │
│ ✅ Múltiplas views do mesmo dado │
│ │
│ QUANDO NÃO USAR: │
│ ❌ CRUD simples │
│ ❌ Consistência forte necessária │
│ ❌ Time pequeno sem experiência │
│ │
│ EXEMPLO PRÁTICO: │
│ E-commerce: Catálogo de produtos │
│ → Escrita: Admin atualiza produto (raro) │
│ → Leitura: Milhões de pageviews (frequente) │
│ → Read model pode ser denormalizado, cacheado, etc. │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ EVENT SOURCING: ARMAZENE EVENTOS, NÃO ESTADO │
│ │
│ TRADICIONAL: │
│ User { name: "João", email: "joao@email.com" } │
│ (só o estado atual) │
│ │
│ EVENT SOURCING: │
│ 1. UserCreated { name: "João", email: "j@email.com" } │
│ 2. EmailChanged { email: "joao@email.com" } │
│ 3. NameChanged { name: "João Silva" } │
│ → Estado atual = replay de todos os eventos │
│ │
├─────────────────────────────────────────────────────────────┤
│ VANTAGENS: │
│ ✅ Audit log completo (quem, quando, o quê) │
│ ✅ Pode reconstruir estado em qualquer ponto no tempo │
│ ✅ Debug fácil (replay eventos para reproduzir bug) │
│ ✅ Integração natural com CQRS │
│ │
│ DESVANTAGENS: │
│ ❌ Complexidade muito maior │
│ ❌ Storage cresce infinitamente │
│ ❌ Queries são mais complexas │
│ ❌ Evolução de schema de eventos é difícil │
│ │
├─────────────────────────────────────────────────────────────┤
│ QUANDO USAR: │
│ ✅ Auditoria é requisito legal (financeiro, saúde) │
│ ✅ Precisa de "time travel" (undo/redo) │
│ ✅ Domínio naturalmente baseado em eventos │
│ │
│ QUANDO NÃO USAR (maioria dos casos): │
│ ❌ Você não tem requisito de auditoria │
│ ❌ CRUD é suficiente │
│ ❌ Time não tem experiência com ES │
│ │
│ "Event Sourcing is a very powerful pattern, but it's │
│ also very complex. Don't use it unless you need it." │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ COMUNICAÇÃO SÍNCRONA (REST, gRPC) │
│ │
│ [Service A] ──request──→ [Service B] │
│ ↑ │ │
│ └────── response ────────┘ │
│ │
│ A espera B responder │
│ │
│ USE QUANDO: │
│ ✅ Você PRECISA da resposta imediatamente │
│ ✅ Operações simples e rápidas (<100ms) │
│ ✅ User-facing requests │
│ │
├─────────────────────────────────────────────────────────────┤
│ COMUNICAÇÃO ASSÍNCRONA (Message Queue, Events) │
│ │
│ [Service A] ──event──→ [Queue] ──event──→ [Service B] │
│ │ │
│ └─ continua sem esperar │
│ │
│ A NÃO espera B │
│ │
│ USE QUANDO: │
│ ✅ Operação pode demorar (processamento batch) │
│ ✅ Não precisa de resposta imediata │
│ ✅ Desacoplamento é importante │
│ ✅ Retry automático é necessário │
│ │
├─────────────────────────────────────────────────────────────┤
│ RECOMENDAÇÃO: │
│ │
│ User request → SÍNCRONO (REST/gRPC) │
│ Background jobs → ASSÍNCRONO (Queue) │
│ Entre microservices → ASSÍNCRONO quando possível │
└─────────────────────────────────────────────────────────────┘
QUAL USAR:
┌────────────────┬─────────────────────────────────────────┐
│ TECNOLOGIA │ QUANDO USAR │
├────────────────┼─────────────────────────────────────────┤
│ RabbitMQ │ Workload tradicional, routing complexo │
│ │ Bom para: Tasks, RPC assíncrono │
├────────────────┼─────────────────────────────────────────┤
│ Apache Kafka │ High throughput, event streaming │
│ │ Bom para: Logs, analytics, event store │
├────────────────┼─────────────────────────────────────────┤
│ AWS SQS │ Serverless, managed, simples │
│ │ Bom para: Tarefas simples em AWS │
├────────────────┼─────────────────────────────────────────┤
│ Redis Streams │ Já usa Redis, precisa de speed │
│ │ Bom para: Cache + queue em um │
├────────────────┼─────────────────────────────────────────┤
│ BullMQ (Node) │ App Node.js, já tem Redis │
│ │ Bom para: Background jobs em Node │
└────────────────┴─────────────────────────────────────────┘
REGRA SIMPLES:
→ Task queue simples? → BullMQ/SQS
→ Event streaming? → Kafka
→ Routing complexo? → RabbitMQ
→ Não sabe? → Comece com SQS/BullMQ
┌────────────────┬─────────────────────────────────────────┐
│ TIPO │ QUANDO USAR │
├────────────────┼─────────────────────────────────────────┤
│ PostgreSQL │ DEFAULT. Relacional, full-featured. │
│ │ Use para: 90% dos casos │
├────────────────┼─────────────────────────────────────────┤
│ MongoDB │ Documentos JSON, schema flexível │
│ │ Use para: Conteúdo, catálogos │
├────────────────┼─────────────────────────────────────────┤
│ Redis │ Cache, sessões, filas │
│ │ Use para: Performance, dados efêmeros │
├────────────────┼─────────────────────────────────────────┤
│ Elasticsearch │ Full-text search, analytics │
│ │ Use para: Busca, logs │
├────────────────┼─────────────────────────────────────────┤
│ ClickHouse │ Analytics, time-series │
│ │ Use para: Dashboards, métricas │
└────────────────┴─────────────────────────────────────────┘
REGRA: Se você não sabe, use PostgreSQL.
PostgreSQL pode fazer:
→ Relacional (óbvio)
→ JSON (JSONB)
→ Full-text search (basic)
→ Time-series (com extensões)
→ Vector search (pgvector)
"PostgreSQL is the everything database."
Usuário: "Estou começando uma startup, devo usar microservices?"
Resposta:
NÃO. Use monolito.
RAZÕES:
1. VOCÊ NÃO TEM OS PROBLEMAS QUE MICROSERVICES RESOLVEM
Microservices resolvem:
→ Times grandes (50+ devs) que não conseguem trabalhar junto
→ Partes do sistema que precisam escalar diferentemente
→ Deploys independentes por diferentes times
Você tem:
→ Time pequeno (1-10 pessoas)
→ Domínio ainda em descoberta
→ Necessidade de velocidade, não escala
2. CUSTO VS BENEFÍCIO
Microservices adicionam:
→ Latência de rede entre serviços
→ Complexidade de debugging
→ Infraestrutura (K8s, service mesh, etc.)
→ Overhead operacional
Para uma startup, isso é MORTAL. Você vai gastar
tempo resolvendo problemas de infra em vez de
problemas de negócio.
3. O QUE FAZER EM VEZ DISSO:
a) MONOLITO MODULAR
→ Separe código em módulos/packages
→ Defina interfaces claras entre módulos
→ Isso facilita extrair serviço DEPOIS se precisar
b) ESTRUTURA SUGERIDA:
/src
/modules
/users
- controller.ts
- service.ts
- repository.ts
/orders
- controller.ts
- service.ts
- repository.ts
/payments
...
/shared
- database.ts
- auth.ts
c) TECNOLOGIA:
→ Node.js + Express/Fastify ou
→ Python + FastAPI ou
→ Go + Chi
→ PostgreSQL
→ Redis para cache/sessions
→ Tudo em uma máquina ou container
4. QUANDO MIGRAR PARA MICROSERVICES:
→ Você tem 50+ devs
→ Deploys estão atrasando porque times se bloqueiam
→ Parte específica precisa escalar 10x mais que resto
→ Você tem time de plataforma dedicado
Até lá: MONOLITO.
"If you can't build a well-structured monolith,
what makes you think microservices are the answer?"
1. SEJA OBJETIVO — dê recomendações específicas
2. Monolito primeiro, sempre (até 50 devs)
3. PostgreSQL é o default
4. Simplicidade > elegância arquitetural
5. Não adicione complexidade sem razão clara
6. "You ain't gonna need it" (YAGNI)
7. Escolha boring technology
8. Arquitetura evolui com o time e produto
9. Modular monolith é melhor que microservices ruins
10. Se não sabe explicar por que precisa, não precisa
Esta skill ativa AUTOMATICAMENTE quando: