Você está numa reunião com o time de engenharia. Eles falam em microsserviços, event sourcing, CQRS e Kubernetes. Você acena com a cabeça, mas metade dos termos parece outro idioma.
Esse glossário existe para resolver isso. São 60 termos de arquitetura de software explicados sem jargão desnecessário — com foco no que cada conceito significa para o negócio, não apenas para o código.
Não é preciso virar engenheiro para tomar boas decisões de tecnologia. Mas conhecer o vocabulário muda completamente a qualidade das conversas com o time técnico.
A — Fundamentos de arquitetura
1. Arquitetura de software
A estrutura geral de um sistema: como os componentes se organizam, se comunicam e onde cada responsabilidade fica. Uma boa arquitetura facilita mudanças futuras; uma ruim transforma cada nova feature em uma semana de retrabalho.
2. Monolito
Aplicação onde todo o código roda como um único bloco. Mais simples de começar, mais difícil de escalar quando a base cresce. A maioria dos sistemas começa como monolito — e não há nada de errado nisso para a fase inicial.
3. Microsserviços
Arquitetura onde o sistema é dividido em serviços pequenos e independentes, cada um com sua própria responsabilidade. Um serviço cuida de pagamentos, outro de usuários, outro de notificações. Permite escalar partes específicas sem escalar o todo — mas exige mais maturidade operacional.
4. Monolito modular
Meio-termo entre monolito e microsserviços: o código roda num único processo, mas está organizado em módulos bem separados com fronteiras claras. Boa escolha para times que querem organização sem a complexidade de operar múltiplos serviços.
5. API (Application Programming Interface)
Contrato que define como dois sistemas conversam. Quando seu e-commerce consulta o estoque do ERP em tempo real, ele usa uma API. É o "plug" que conecta sistemas diferentes.
6. REST
Estilo arquitetural mais comum para APIs web. Usa os verbos HTTP (GET, POST, PUT, DELETE) para representar operações. Se o seu sistema tem uma API, provavelmente é REST.
7. GraphQL
Alternativa ao REST onde o cliente especifica exatamente quais dados quer receber. Reduz o tráfego de rede em apps mobile e acelera o desenvolvimento frontend — mas adiciona complexidade no backend.
8. gRPC
Protocolo de comunicação de alta performance usado principalmente entre microsserviços internos. Mais rápido que REST, mas não funciona diretamente no browser. Comum em sistemas com altíssimo volume de chamadas internas.
B — Dados e persistência
9. Banco de dados relacional
Banco com tabelas, colunas e relacionamentos bem definidos. PostgreSQL, MySQL e SQL Server são os mais comuns. Excelente para dados estruturados com regras de integridade claras — pedidos, clientes, transações financeiras.
10. Banco de dados NoSQL
Categoria de bancos que não usam o modelo relacional. MongoDB (documentos), Redis (chave-valor), Cassandra (colunar). Mais flexíveis para dados variados ou de altíssimo volume, mas sem as garantias de integridade do relacional.
11. ORM (Object-Relational Mapper)
Ferramenta que permite ao desenvolvedor trabalhar com o banco de dados usando código, sem escrever SQL manualmente. Entity Framework Core (no .NET) e Hibernate (Java) são exemplos. Agiliza o desenvolvimento, mas pode gerar queries ruins se usado sem cuidado.
12. Migration
Arquivo versionado que registra uma mudança na estrutura do banco de dados — adicionar coluna, criar tabela, alterar tipo de campo. Funciona como um "histórico de versões" do banco, permitindo aplicar ou reverter mudanças de forma controlada.
13. Cache
Camada de memória que guarda resultados de operações custosas para evitar recalculá-las. Se mil usuários pedem o mesmo relatório, o cache entrega a versão já calculada sem bater no banco. Redis é a ferramenta de cache mais popular.
14. ACID
Conjunto de garantias de um banco de dados confiável: Atomicidade (tudo ou nada), Consistência (dados sempre válidos), Isolamento (transações não interferem entre si) e Durabilidade (dados gravados não somem). Fundamental para sistemas financeiros.
C — Padrões de design e domínio
15. DDD (Domain-Driven Design)
Abordagem onde o código é organizado ao redor do negócio, não da tecnologia. O sistema fala a linguagem do domínio: "Pedido", "Cliente", "Fatura" — não "tabela_pedidos" e "FK_cliente_id". Reduz o atrito entre o que o negócio precisa e o que o sistema faz.
16. Entidade
Objeto do sistema que tem identidade própria e muda ao longo do tempo. Um Cliente é uma entidade — tem ID único e seus dados evoluem. Diferente de um Endereço, que é um valor associado ao cliente.
17. Agregado
Grupo de entidades tratadas como uma unidade para fins de consistência. Um Pedido com seus Itens é um agregado: você não altera os itens diretamente — passa pelo Pedido. Garante que as regras de negócio sejam sempre respeitadas.
18. Repositório
Camada de abstração que isola o acesso ao banco de dados. O código de negócio pede "me dê o Pedido #123" e o repositório sabe como buscar isso no banco. Facilita testes e troca de tecnologia de persistência.
19. CQRS (Command Query Responsibility Segregation)
Padrão que separa as operações de leitura das de escrita. O comando "Criar Pedido" segue um caminho; a query "Listar Pedidos" segue outro. Permite otimizar cada lado independentemente — escrita com consistência forte, leitura com performance máxima.
20. Event Sourcing
Em vez de salvar apenas o estado atual, salva todos os eventos que levaram a ele. Um saldo de conta bancária não é um número — é a sequência de depósitos e saques. Permite auditoria completa e reconstrução do estado em qualquer ponto do tempo.
21. Clean Architecture
Estrutura de código onde as regras de negócio ficam no centro, completamente isoladas de bancos de dados, frameworks e interfaces. O código do domínio não sabe se está sendo acessado por uma API REST, uma fila de mensagens ou um teste automatizado.
22. Injeção de dependência
Técnica onde um componente recebe suas dependências de fora, em vez de criá-las internamente. Facilita a troca de implementações e a escrita de testes. A maioria dos frameworks modernos oferece suporte nativo.
D — Mensageria e comunicação assíncrona
23. Mensageria
Sistema onde serviços se comunicam enviando mensagens para filas ou tópicos, sem esperar resposta imediata. Um serviço publica "Pedido criado" e outros serviços reagem quando conveniente — sem acoplamento direto entre eles.
24. Fila (Queue)
Canal onde mensagens são enfileiradas e processadas uma a uma. O produtor coloca mensagens; o consumidor retira e processa. RabbitMQ é o gerenciador de filas mais popular no ecossistema .NET/cloud.
25. Tópico (Topic / Pub-Sub)
Canal onde uma mensagem publicada é entregue a múltiplos consumidores simultaneamente. "Pedido criado" dispara para o serviço de e-mail, o de estoque e o de analytics ao mesmo tempo — sem o publicador saber quem está ouvindo.
26. Kafka
Plataforma de streaming distribuído para altíssimo volume de eventos. Enquanto RabbitMQ foca em filas de tarefas, Kafka foca em logs imutáveis de eventos que podem ser relidos. Comum em empresas com milhões de eventos por dia.
27. Dead Letter Queue (DLQ)
Fila especial para mensagens que falharam após várias tentativas de processamento. Em vez de perder a mensagem ou travar a fila principal, ela vai para a DLQ para análise e reprocessamento manual.
28. Outbox Pattern
Técnica que garante que uma mensagem seja publicada na fila se e somente se a transação do banco for confirmada. Resolve o problema clássico de "salvei no banco mas a mensagem sumiu" — ou vice-versa.
E — Infraestrutura e operação
29. Container
Unidade padronizada de software que empacota o código e todas suas dependências. Um container Docker roda igual em qualquer ambiente — desenvolvimento, homologação ou produção. Elimina o famoso "funciona na minha máquina".
30. Docker
A plataforma de containers mais popular. Permite criar, distribuir e rodar containers. Quase todo sistema moderno usa Docker no pipeline de deploy.
31. Kubernetes (K8s)
Sistema de orquestração de containers. Decide em qual máquina cada container roda, reinicia containers que falham, escala automaticamente conforme a carga. É como um gerente de infraestrutura automatizado.
32. Cloud (Nuvem)
Infraestrutura de servidores, armazenamento e serviços gerenciados fornecida por terceiros (AWS, Azure, GCP). Você paga pelo que usa, sem comprar hardware. Reduz custo inicial mas exige atenção ao custo recorrente.
33. IaaS / PaaS / SaaS
Três níveis de serviço em nuvem. IaaS (Infrastructure): você gerencia o servidor, o provedor fornece o hardware (ex: EC2 na AWS). PaaS (Platform): você gerencia o código, o provedor gerencia o servidor (ex: Azure App Service). SaaS (Software): você usa o produto pronto (ex: Salesforce, Notion).
34. Terraform
Ferramenta de Infraestrutura como Código (IaC). Em vez de clicar em painéis de cloud para criar recursos, você escreve arquivos de configuração e a infraestrutura é criada automaticamente — e de forma repetível.
35. CI/CD (Integração Contínua / Entrega Contínua)
Pipeline automatizado que vai do commit do desenvolvedor até o deploy em produção. CI garante que o código compila e os testes passam. CD automatiza o deploy. Um time maduro faz deploy várias vezes por dia com segurança.
36. GitHub Actions
Plataforma de CI/CD integrada ao GitHub. Permite definir workflows automatizados em arquivos YAML: "quando alguém fizer merge na main, rodar testes e fazer deploy". É a escolha padrão para times que usam GitHub.
37. Load Balancer (Balanceador de carga)
Componente que distribui as requisições entre múltiplas instâncias de um serviço. Se você tem 3 servidores rodando a API, o load balancer garante que nenhum fique sobrecarregado enquanto os outros ficam ociosos.
38. Auto Scaling
Capacidade de aumentar ou diminuir automaticamente o número de instâncias conforme a demanda. Na Black Friday, o sistema sobe mais servidores. Na madrugada, desce. Você paga pelo que usa.
39. CDN (Content Delivery Network)
Rede de servidores distribuída geograficamente que entrega arquivos estáticos (imagens, CSS, JS) do ponto mais próximo ao usuário. Reduz latência e alivia o servidor principal. Cloudflare é a CDN mais usada.
F — Qualidade e segurança
40. Testes unitários
Testes que verificam o comportamento de uma única função ou método em isolamento. São rápidos de rodar e encontram bugs cedo. Um bom conjunto de testes unitários é a primeira linha de defesa contra regressões.
41. Testes de integração
Testes que verificam se dois ou mais componentes funcionam corretamente juntos — por exemplo, o serviço de pedidos funcionando com o banco de dados real. Mais lentos que unitários, mas detectam problemas que testes isolados não veem.
42. Cobertura de testes
Percentual do código coberto por testes automatizados. 80% de cobertura significa que 80% das linhas de código são executadas durante os testes. Alta cobertura não garante ausência de bugs, mas reduz significativamente o risco de regressões.
43. Code Review
Processo onde outros desenvolvedores revisam o código antes de ser mesclado. Detecta bugs, garante aderência aos padrões e dissemina conhecimento pelo time. Times maduros tratam code review como parte do fluxo, não como burocracia.
44. Débito técnico
Custo acumulado de decisões de atalho tomadas no passado. Como uma dívida financeira, o débito técnico tem juros: quanto mais tempo sem pagar, mais caro fica. Sistemas com muito débito técnico têm features que levam semanas para sair e bugs que nunca somem de vez.
45. JWT (JSON Web Token)
Formato compacto para transmitir informações de autenticação entre sistemas. Quando o usuário faz login, recebe um JWT. Em cada requisição seguinte, apresenta esse token para provar que está autenticado — sem o servidor precisar consultar o banco a cada chamada.
46. OAuth 2.0 / OIDC
Protocolos padrão para autenticação e autorização. Quando você usa "Entrar com Google", está usando OAuth 2.0. OIDC adiciona camada de identidade ao OAuth. São a base dos sistemas de login modernos e seguros.
47. Rate Limiting
Mecanismo que limita quantas requisições um cliente pode fazer em determinado período. Protege a API contra abuso, ataques de força bruta e clientes com bug que disparam chamadas em loop.
48. LGPD / GDPR
Legislações de proteção de dados pessoais. LGPD no Brasil, GDPR na Europa. Impõem regras sobre coleta, armazenamento e uso de dados de usuários. Todo sistema que guarda dados de pessoas precisa estar em conformidade.
G — Observabilidade e performance
49. Observabilidade
Capacidade de entender o que está acontecendo dentro de um sistema a partir de seus outputs externos. Um sistema observável permite responder "por que a latência aumentou?" sem precisar adivinhar. Três pilares: logs, métricas e traces.
50. Logs
Registros textuais de eventos que aconteceram no sistema. "Usuário 123 fez login às 14:32". Logs estruturados (em JSON) facilitam a busca e análise automatizada. Serilog e ELK Stack são ferramentas comuns.
51. Métricas
Medidas numéricas ao longo do tempo: requisições por segundo, tempo de resposta médio, uso de CPU. Armazenadas em ferramentas como Prometheus e visualizadas em dashboards como Grafana.
52. Trace distribuído
Registro do caminho completo de uma requisição por múltiplos serviços. Permite responder "essa operação demorou 3 segundos — onde o tempo foi gasto?" em sistemas distribuídos. OpenTelemetry é o padrão aberto do setor.
53. SLA / SLO / SLI
Três níveis de acordos de nível de serviço. SLI (Indicador): a métrica medida, ex. "99,2% das requisições responderam em menos de 500ms". SLO (Objetivo): a meta interna, ex. "99,5%". SLA (Acordo): o compromisso contratual com o cliente, ex. "99% de disponibilidade".
54. Latência
Tempo que uma operação leva para ser concluída. Latência de API é o tempo entre o cliente enviar a requisição e receber a resposta. Alta latência degrada a experiência do usuário mesmo quando o sistema está tecnicamente "funcionando".
55. Throughput
Quantidade de trabalho realizado por unidade de tempo. Uma API com throughput de 10.000 requisições por segundo aguenta mais carga que uma com 1.000. Importante para dimensionar infraestrutura para picos de acesso.
H — Arquitetura de produto e processo
56. Feature Flag
Mecanismo que ativa ou desativa funcionalidades sem fazer novo deploy. Permite lançar uma feature para 5% dos usuários antes de ativar para todos — reduzindo o risco de um lançamento completo e permitindo rollback instantâneo se algo der errado.
57. Canary Release
Estratégia de deploy onde a nova versão é entregue para uma pequena porcentagem dos usuários antes de ser liberada para todos. Se a "canária" não morrer (sem erros), o rollout continua. Se der problema, apenas uma fração dos usuários foi impactada.
58. Blue-Green Deployment
Técnica de deploy com zero downtime: mantém dois ambientes idênticos (azul e verde). A nova versão vai para o verde enquanto o azul ainda atende usuários. Quando tudo está validado, o tráfego é chaveado para o verde em segundos.
59. Discovery técnico
Fase inicial de um projeto onde o time investiga o problema, define a solução e estima o esforço antes de começar a codar. Reduz drasticamente o risco de construir a coisa errada ou subestimar o projeto. Um bom discovery vale cada centavo investido.
60. Roadmap de produto
Plano visual que comunica a direção do produto ao longo do tempo — o que será construído, em que ordem e por quê. Não é uma lista de features gravada em pedra; é um instrumento de alinhamento entre negócio, produto e engenharia que deve evoluir conforme o contexto muda.
Como usar este glossário no dia a dia
Conhecer esses termos não transforma um gestor em engenheiro — nem precisa. O objetivo é diferente: aumentar a qualidade das conversas entre negócio e tecnologia.
Quando o CTO fala em "aumentar a observabilidade do sistema", você sabe que está falando em investir em logs, métricas e traces para entender melhor o que acontece em produção — não apenas em "monitoramento genérico".
Quando o time propõe migrar para microsserviços, você consegue fazer as perguntas certas: "temos maturidade operacional para isso?", "faz sentido agora ou é otimização prematura?"
Linguagem compartilhada é a base de decisões técnicas melhores. E decisões técnicas melhores constroem produtos melhores.
Se quiser aprofundar em algum desses conceitos no contexto do seu sistema, a Neryx oferece um processo de Discovery que começa justamente por aí — entender o que você tem e o que faz sentido construir.