Estudo: Guia Essencial de Arquitetura de Sistemas¶

1. O que é Arquitetura de Software?¶

Arquitetura de software define a estrutura de um sistema: seus componentes, como eles interagem e as regras que governam sua evolução.

Mais do que um diagrama, é o entendimento compartilhado sobre as decisões de design mais importantes — aquelas que são difíceis de mudar no futuro.

Uma boa arquitetura acelera o desenvolvimento e reduz custos a longo prazo, sendo crucial para o sucesso do negócio.

O arquiteto de software guia essas decisões importantes, garantindo que o sistema atenda a requisitos de escalabilidade, segurança e desempenho.

2. Princípios Fundamentais¶

2.1. Atributos de Qualidade (Requisitos Não Funcionais)¶

Atributos de qualidade definem como um sistema deve operar. Eles são os principais direcionadores das decisões arquiteturais e incluem:

Escalabilidade: Capacidade de lidar com o aumento de carga.
Manutenibilidade: Facilidade para modificar ou corrigir o sistema.
Desempenho: Velocidade e responsividade do sistema.
Segurança: Proteção contra acesso não autorizado.
Disponibilidade: Garantia de que o sistema está operacional quando necessário.

2.2. A Arte do Trade-off¶

A primeira lei da arquitetura é: tudo é um trade-off.

Não existe solução perfeita. Cada escolha otimiza um atributo em detrimento de outro. Ignorar isso gera dívida técnica.

Exemplos comuns incluem:

Desempenho vs. Escalabilidade: Otimizar para baixa latência pode dificultar a distribuição da carga.
Custo vs. Confiabilidade: Alta disponibilidade exige redundância, o que aumenta os custos.
Segurança vs. Usabilidade: Controles de segurança rigorosos podem adicionar complexidade para o usuário.

Teorema CAP: Um sistema só pode garantir duas de três propriedades: Consistência (C), Disponibilidade (A) e Tolerância a Partições (P). Como falhas de rede (P) são inevitáveis, a escolha real é entre consistência e disponibilidade.

2.3. A Lei de Conway¶

A Lei de Conway afirma que a arquitetura do software espelha a estrutura de comunicação da equipe que o constrói.

Equipes divididas em silos produzem sistemas fragmentados.
A solução é a "Manobra Inversa de Conway": moldar a equipe para produzir a arquitetura desejada.
Exemplo: Times pequenos e autônomos criam microsserviços.

3. Estilos Arquiteturais¶

3.1. Monolito¶

Vantagens: Simplicidade inicial no desenvolvimento e implantação.
Desvantagens: Com o crescimento, a manutenção se torna complexa, a escalabilidade é ineficiente e as implantações são arriscadas.

3.2. Microsserviços¶

Vantagens: Escalabilidade granular, agilidade para as equipes, resiliência e liberdade tecnológica.
Desvantagens: A complexidade se move do código para a infraestrutura, exigindo gerenciamento de sistemas distribuídos.

3.3. Arquitetura Orientada a Serviços (SOA)¶

Precursora dos microsserviços, com serviços maiores e de escopo corporativo.
Geralmente integrados por um Barramento de Serviço (ESB) central.

3.4. Arquitetura Orientada a Eventos (EDA)¶

Comunicação assíncrona através de eventos.
Promove desacoplamento máximo, escalabilidade e resiliência.

4. Tabela Comparativa de Estilos¶

Característica	Monolito	SOA	Microsserviços	EDA
Granularidade	Aplicação única	Serviços de negócio (grosso)	Serviços de função única (fino)	Serviços reativos a eventos
Acoplamento	Forte	Fraco (via ESB)	Muito fraco	Extremamente fraco
Comunicação	Em processo	Síncrona (via ESB)	Síncrona (API) ou Assíncrona	Assíncrona (eventos)
Consistência	Forte (ACID)	Forte (dentro do serviço)	Eventual (entre serviços)	Eventual por natureza
Escalabilidade	Unidade inteira	Limitada pelo ESB	Granular e horizontal	Altamente elástica
Complexidade	Baixa no início, alta em escala	Alta (governança, ESB)	Alta (operacional)	Alta (fluxo de dados)

5. Elementos da Arquitetura de Sistemas¶

5.1. Camadas¶

A arquitetura de sistemas frequentemente é organizada em camadas, cada uma responsável por diferentes aspectos do funcionamento do sistema:

Camada de Apresentação: gerencia a interface do usuário e a interação com o sistema.
Camada de Aplicação: trata a lógica de negócios e as regras de operação.
Camada de Dados: responsável pelo armazenamento, recuperação e manipulação dos dados.

5.2. Serviços¶

Serviços são componentes independentes que executam funções específicas dentro de um sistema. Eles promovem reutilização e modularidade.

Tipos de serviços:

Microservices (Microserviços): pequenas aplicações que executam uma única função. Exemplo: serviço de autenticação.
Web Services: APIs que permitem comunicação entre sistemas via protocolos como HTTP/HTTPS. Exemplo: serviço de previsão do tempo.
SOA (Service-Oriented Architecture): abordagem em que os serviços são blocos de construção principais, como processamento de pagamento ou gestão de inventário.

5.3. Interfaces¶

Interfaces definem como diferentes componentes do sistema interagem entre si, especificando métodos e protocolos de comunicação para garantir compatibilidade e integração.

5.4. Protocolos de Comunicação¶

Protocolos estabelecem as regras e formatos para troca de dados entre componentes, assegurando segurança e eficiência.

Exemplos:

HTTP (Hypertext Transfer Protocol): usado para transferência de páginas e recursos na web.
TCP/IP (Transmission Control Protocol/Internet Protocol): base da comunicação na internet.
WebSockets: comunicação bidirecional em tempo real, útil para chats online e streaming.

5.5. Padrões de Design¶

Padrões de design são soluções reutilizáveis para problemas comuns no desenvolvimento de software, ajudando a garantir robustez e facilidade de manutenção.

6. Padrões para Sistemas Distribuídos¶

Adotar microsserviços exige resolver desafios de comunicação, descoberta e consistência de dados.

6.1. Padrões de Comunicação¶

Síncrona vs. Assíncrona:
- Síncrona: API REST (cliente bloqueia até resposta).
- Assíncrona: Filas de mensagens (desacopla serviços, aumenta resiliência).
API REST vs. gRPC:
- REST: HTTP/1.1 + JSON (simples e legível).
- gRPC: HTTP/2 + Protocol Buffers (rápido, eficiente).
Filas de Mensagens:
- Atuam como buffer para mensagens.
- Garantem entrega confiável.
- Permitem que serviços operem de forma independente.

6.2. Padrões de Descoberta e Roteamento¶

API Gateway: Ponto de entrada único para requisições, centralizando autenticação, logging e limitação de taxa.
Service Discovery: Serviços encontram uns aos outros dinamicamente, usando um Service Registry.

6.3. Padrão de Consistência de Dados¶

Saga:
- Gerencia transações que abrangem múltiplos serviços.
- Usa transações locais + compensações em caso de falha.
- Garante consistência eventual.

7. A Prática da Arquitetura¶

7.1. Architecture Decision Records (ADRs)¶

Documentos concisos que registram uma decisão arquitetural, seu contexto e consequências.
Combatem a "amnésia do projeto", explicando o porquê das escolhas.

7.2. Observabilidade¶

Capacidade de entender o estado do sistema a partir de dados externos.

Logs: Registros de eventos discretos.
Métricas: Dados numéricos agregados ao longo do tempo.
Traces: Caminho completo de uma requisição entre serviços.

7.3. Migração com Strangler Fig Pattern¶

Estratégia para modernizar monolitos sem risco.
Um proxy intercepta tráfego.
Novas funcionalidades são criadas como microsserviços.
Tráfego é gradualmente redirecionado até desativar o legado.

8. Estudos de Caso¶

Netflix: Usou microsserviços para alcançar escalabilidade e disponibilidade massivas em streaming, aceitando alta complexidade operacional.
Uber: Adotou microsserviços para lidar com escala organizacional e acelerar a inovação.
Spotify: Focou primeiro na cultura organizacional (Squads, Tribes), moldando naturalmente uma arquitetura ágil.

9. Análise da Arquitetura de Sistemas da Netflix¶

9.1. Problema Original¶

Início: monólito em datacenter próprio.
Desafios: escalar, alta disponibilidade e baixa latência global.
Solução: migração para AWS + microsserviços.

9.2. Microsserviços¶

Catálogo → lista de filmes/séries.
Recomendações → sugestões personalizadas.
Autenticação → login e segurança.
Streaming → vídeo adaptativo.
Billing → pagamentos.

Cada serviço é independente, escalável e atualizável.

9.3. Comunicação entre Serviços¶

API Gateway → entrada única (apps e web).
REST/gRPC → comunicação interna.
Kafka → eventos assíncronos (histórico, estatísticas, recomendações).

9.4. Entrega de Vídeo (CDN – Open Connect)¶

CDN própria com servidores de cache nos ISPs.
Conteúdo entregue do ponto mais próximo → menos latência e menor custo de banda.

9.5. Escalabilidade e Resiliência¶

Elastic Load Balancing → distribui requisições.
Auto-scaling (AWS) → adapta a demanda (picos em estreias).
Chaos Engineering (Simian Army/Chaos Monkey) → falhas simuladas para testar resiliência.

9.6. Observabilidade¶

Logs centralizados.
Métricas em tempo real (ex: streams/segundo).
Tracing distribuído (acompanha requisições entre microsserviços).

9.7. Experiência do Usuário¶

Recomendações personalizadas (histórico).
Testes A/B (interface, imagens, algoritmos).
Machine Learning → prever engajamento de conteúdo.

9.8. Resumo da Arquitetura¶

Microsserviços desacoplados.
API Gateway unificada.
Kafka para eventos assíncronos.
Open Connect (CDN própria).
Escalabilidade (AWS + load balancing + auto-scaling).
Resiliência (Chaos Engineering).
Observabilidade avançada.
Personalização com dados e ML.

9.9. Prós e Contras da Decisão da Netflix: Monólito → Microsserviços¶

9.9.1. Prós¶

Escalabilidade: cada serviço pode crescer independentemente.
Resiliência: falhas em um serviço não derrubam todo o sistema.
Agilidade: times pequenos podem desenvolver e implantar autonomamente.
Personalização: dados e ML aplicados de forma modular.
Infraestrutura global: CDN própria reduz latência e custos.

9.9.2. Contras¶

Complexidade operacional: muitos serviços distribuídos para gerenciar.
Maior overhead de comunicação: APIs internas e mensageria aumentam a complexidade.
Dependência de cloud: custos e configuração de auto-scaling e balanceamento.