<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <docs>https://blogs.law.harvard.edu/tech/rss</docs>
    <title>Arquitetura on FXShell - DevOps &amp; Sec</title>
    <link>https://fxshelll.github.io/tags/arquitetura/</link>
    <description>Recent content in Arquitetura on FXShell - DevOps &amp; Sec</description>
    <image>
      <title>Arquitetura on FXShell - DevOps &amp; Sec</title>
      <link>https://fxshelll.github.io/tags/arquitetura/</link>
      <url>fxshell.png</url>
    </image>
    <ttl>1440</ttl>
    <generator>Hugo 0.152.2</generator>
    <language>pt-br</language>
    <lastBuildDate>Mon, 04 May 2026 02:18:57 UT</lastBuildDate>
    <atom:link href="https://fxshelll.github.io/tags/arquitetura/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Monolito, Arquitetura em Camadas e Microsserviços</title>
      <link>https://fxshelll.github.io/posts/arquitetura-de-aplica%C3%A7%C3%B5es/</link>
      <pubDate>Wed, 24 Sep 2025 12:00:00 UT</pubDate>
      <dc:creator>Felipe da Matta</dc:creator>
      <guid>https://fxshelll.github.io/posts/arquitetura-de-aplica%C3%A7%C3%B5es/</guid>
      <description>A maioria dos sistemas começa como um monólito. E não tem problema algum nisso. O problema é quando o monólito cresce sem nenhuma organização interna, e o time começa a gastar mais tempo desvendando dependências ocultas do que entregando funcionalidades.
Este post cobre a evolução natural das arquiteturas de software — do monólito para a arquitetura em camadas e, em determinados contextos, para microsserviços — com ênfase nos trade-offs reais de cada abordagem.
</description>
      <content:encoded><![CDATA[A maioria dos sistemas começa como um monólito. E não tem problema algum nisso. O problema é quando o monólito cresce sem nenhuma organização interna, e o time começa a gastar mais tempo desvendando dependências ocultas do que entregando funcionalidades.
Este post cobre a evolução natural das arquiteturas de software — do monólito para a arquitetura em camadas e, em determinados contextos, para microsserviços — com ênfase nos trade-offs reais de cada abordagem.
Visão Geral Monólito: uma aplicação única, um deploy para tudo. Arquitetura em Camadas: organização interna em camadas (UI, aplicação, domínio, infra) — ainda um único deploy. Microsserviços: várias aplicações pequenas e independentes, comunicando-se via APIs ou eventos. 1. Monólito Uma aplicação única, com todas as funcionalidades, que roda e é implantada como um bloco só.
Quando usar Produtos em fase inicial. Equipes pequenas. Domínio ainda pouco definido. Vantagens Simples de desenvolver, testar e implantar. Transações ACID fáceis (um único banco). Performance interna (chamadas em memória, sem latência de rede). Custos operacionais menores no início. Desafios Acoplamento crescente — evolução fica difícil com o tempo. Deploy único significa risco alto: qualquer mudança afeta o sistema inteiro. Escalabilidade desigual — para escalar um módulo, escala tudo junto. Sem estrutura interna, vira o famoso Big Ball of Mud. Boas práticas Organizar em módulos separados (Monólito Modular). Usar camadas bem definidas (UI, domínio, infra). Aplicar DDD leve (entidades, serviços de domínio). Adotar CI/CD e feature flags para reduzir risco nos deploys. 2. Arquitetura em Camadas (Layered) Estilo de organização interna que pode ser aplicado tanto em monólitos quanto em microsserviços. Não é um tipo de deploy — é uma forma de estruturar o código.
Camadas típicas Apresentação (UI/API): controllers, validações, DTOs. Aplicação/Serviços: orquestra casos de uso. Domínio (Core): entidades, regras de negócio, policies. Infraestrutura: persistência, mensageria, APIs externas. Benefícios Separação de responsabilidades clara. Testabilidade alta — cada camada pode ser testada de forma isolada. Evolução mais segura — mudanças ficam contidas na camada correta. Cuidados Evitar modelo anêmico (entidades sem lógica, só getters/setters). Respeitar a direção de dependências: UI → App → Domínio → Infra. Não deixar detalhes de infraestrutura vazar para o domínio. 3. Microsserviços Conjunto de serviços pequenos e autônomos, cada um dono do próprio banco e alinhado a um subdomínio de negócio específico.
Quando faz sentido Domínio já estável e bem mapeado. Necessidade de escala granular (diferentes partes do sistema têm cargas diferentes). Múltiplas equipes (squads) precisam trabalhar de forma autônoma. Deploys independentes e resiliência a falhas são prioridade. Vantagens Escala por serviço — paga pela infraestrutura do que precisa. Deploy independente — atualiza um serviço sem afetar os outros. Autonomia de tecnologia — cada serviço pode usar a stack mais adequada. Resiliência a falhas locais — um serviço caindo não derruba o sistema todo. Desafios Complexidade distribuída — rede, latência, retries, timeouts. Dados distribuídos — consistência eventual em vez de ACID. Observabilidade — logs, métricas e tracing distribuído são obrigatórios. Governança — versionamento de contratos e APIs. Custos operacionais maiores (mais infraestrutura, mais orquestração). Boas práticas Definir Bounded Contexts (DDD) antes de cortar serviços. Um banco por serviço — nunca banco compartilhado. Preferir comunicação assíncrona (eventos, filas) para desacoplamento. Usar contratos versionados. Implementar padrões de resiliência: circuit breaker, timeout, retries. Adotar OpenTelemetry e tracing distribuído desde o início. 4. Comparativo Critério Monólito Microsserviços Time-to-market inicial Excelente Bom (overhead de setup) Complexidade Baixa Alta Escalabilidade Fraca (escala tudo) Forte (por serviço) Deploy independente Não Sim Consistência Forte (ACID) Eventual (Sagas) Tamanho de equipe Pequena Média/Grande Custos iniciais Baixos Altos Evolução longo prazo Pode degradar Alta (se bem governada) 5. Estratégias de Migração Migrar de monólito para microsserviços não é um projeto de fim de semana. As estratégias mais usadas:
Strangler Fig: cercar o monólito e extrair features aos poucos, sem interrupção. Modularizar internamente antes de separar em serviços. Usar Anticorruption Layer para integrar com sistemas legados sem contaminar o domínio novo. Definir estratégia de dados (sagas, eventos) antes de separar os bancos. Começar pelos hotspots — módulos com mais dor de escala ou frequência de mudança. 6. Banco de Dados em Microsserviços SQL (Relacional) Bancos como PostgreSQL, MySQL e SQL Server são ideais para sistemas que exigem integridade transacional.
Transações ACID — Atomicidade, Consistência, Isolamento e Durabilidade. Consultas complexas com JOIN, agregações e filtros avançados. Integridade referencial assegurada por chaves e restrições. Quando usar: pagamentos, pedidos, autenticação — qualquer fluxo onde a consistência forte é inegociável.
NoSQL (Não Relacional) Bancos como MongoDB, Cassandra e Redis oferecem flexibilidade e escalam bem em ambientes distribuídos.
Flexibilidade de esquema — sem estrutura fixa de tabelas. Escalabilidade horizontal — adiciona nós conforme o volume cresce. Consistência eventual, priorizando disponibilidade e desempenho. Quando usar: catálogos de produtos, sessões, dados de IoT, histórico de eventos.
Teorema CAP Todo sistema distribuído precisa escolher entre duas das três propriedades:
Propriedade Descrição Consistência (C) Todos os nós veem os mesmos dados ao mesmo tempo. Disponibilidade (A) O sistema sempre responde, mesmo com falhas. Tolerância a Partições (P) O sistema continua operando mesmo que partes da rede falhem. Bancos SQL priorizam Consistência + Disponibilidade. Bancos NoSQL priorizam Disponibilidade + Particionamento, aceitando consistência eventual.
Padrões para dados distribuídos Database per Service — cada microsserviço tem seu próprio banco. Nunca banco compartilhado entre domínios. Isso garante autonomia de deploy e escala independente.
CQRS (Command Query Responsibility Segregation) — separa as operações de escrita (commands) das de leitura (queries). Permite otimizações específicas para cada tipo: banco relacional para escrita, Elasticsearch para leitura, por exemplo.
Event Sourcing — cada mudança de estado é registrada como um evento imutável. A aplicação reconstrói seu estado a partir desses eventos. Garante rastreabilidade total e histórico auditável.
Sagas — coordenam transações distribuídas usando eventos assíncronos. Cada etapa tem uma ação compensatória caso algo falhe, garantindo consistência eventual sem bloqueios distribuídos (2PC).
7. Comunicação entre Microsserviços A forma como os serviços se comunicam define a qualidade do sistema inteiro. Existem três modelos principais.
Comunicação Síncrona (REST / gRPC) O cliente faz uma requisição e espera pela resposta. É o modelo clássico — simples, direto e previsível.
REST / HTTP é o mais comum. Simples de implementar, bem suportado em qualquer linguagem, mas cria acoplamento temporal: se o servidor cai, o cliente também quebra.
gRPC é mais moderno e performático. Usa serialização binária (Protocol Buffers), suporta streams bidirecionais e define contratos fortemente tipados. Mais rápido que JSON/REST e ideal para comunicação interna entre microsserviços. A desvantagem é a complexidade maior e dificuldade de expor diretamente para o frontend.
Quando usar: operações críticas em tempo real onde a resposta importa imediatamente — consultas de saldo, validação de pagamento, autenticação.
Comunicação Assíncrona (Kafka / RabbitMQ) O cliente envia uma mensagem e não espera resposta. O servidor processa quando puder, usando filas ou streams.
Tecnologias: Kafka, RabbitMQ, AWS SQS, NATS, Pulsar.
Vantagens: desacoplamento temporal, alta resiliência, absorve picos de tráfego. Se um consumidor cai, as mensagens ficam na fila até ele voltar.
Desafios: exige infraestrutura de broker, tratamento de retries, deduplicação e Dead Letter Queue (DLQ). Debug mais complexo — tracing distribuído é obrigatório.
Quando usar: propagação de eventos, notificações, processamento em background — qualquer fluxo onde o produtor não precisa esperar o resultado.
API Gateway Um ponto único de entrada que recebe, roteia e controla as requisições para os microsserviços internos. Exemplos: Kong, Traefik, Apigee, Amazon API Gateway.
O gateway centraliza: autenticação e autorização, rate limiting, transformação de payloads, métricas e observabilidade.
O risco é virar um ponto único de falha — precisa de alta disponibilidade e bom monitoramento.
Padrão híbrido (REST + Mensageria) Na prática, os sistemas saudáveis usam os dois modelos:
REST/gRPC para operações rápidas e críticas que precisam de resposta imediata. Kafka/RabbitMQ para propagação de eventos e processamento assíncrono. Exemplo: pedido criado via REST → evento PedidoCriado publicado no Kafka → estoque, faturamento e notificação consomem de forma independente.
8. Anti-padrões Banco de dados compartilhado entre serviços (o maior assassino de autonomia). Nanosserviços — fragmentação excessiva sem justificativa de negócio. Comunicação síncrona em cascata — A chama B que chama C que chama D. Um nó lento trava toda a cadeia. Migração &ldquo;big bang&rdquo; — tentar migrar tudo de uma vez. Serviços sem CI/CD e sem observabilidade. 9. Quando Migrar para Microsserviços Manter o Monólito se O time é pequeno. O produto está no início. A escalabilidade é resolvível com cache/CDN. Deploys menos frequentes são aceitáveis. Migrar para Microsserviços se O contexto de negócio está bem delimitado e estável. Existe dor real de escala ou necessidade de releases independentes. O plano de observabilidade e dados está definido. A estratégia de contratos e versionamento está estabelecida. Conclusão Comece com monólito modular em camadas. Organize o código internamente, defina bounded contexts, mantenha boa cobertura de testes. Evolua para microsserviços onde realmente existe dor — escala, autonomia de equipe, deploys independentes.
A tendência do mercado não é escolher um modelo e ficar nele para sempre. É entender que cada parte do sistema pode ter uma arquitetura diferente, e que a decisão certa depende da maturidade do domínio, do tamanho do time e da carga real.
Arquitetura é sobre trade-offs. Toda escolha tem custo. A pergunta não é &ldquo;qual é a melhor arquitetura?&rdquo;, mas &ldquo;qual é a melhor arquitetura para esse contexto, agora?&rdquo;.
Referências Martin Fowler — Microservices Martin Fowler — Strangler Fig Application CAP Theorem — Eric Brewer CQRS — Martin Fowler Saga Pattern — microservices.io gRPC — Documentação Oficial OpenTelemetry — Documentação Oficial ]]></content:encoded>
    </item>
  </channel>
</rss>
