Atividade - Arquiteturas de Sistemas Distribuídos: Análise Comparativa, Aplicações Práticas e Tomada de Decisão em Ambientes Modernos - Guia Básico

Atividade - Arquiteturas de Sistemas Distribuídos Análise Comparativa, Aplicações Práticas e Tomada de Decisão em Ambientes Modernos - Guia Básico

Cenários Apresentados para o Estudo de Arquiteturas de Sistemas Distribuídos
 
Empresas modernas utilizam diferentes arquiteturas de sistemas distribuídos conforme seus objetivos, como escalabilidade, desempenho e resiliência. No entanto, não existe uma solução única: cada arquitetura apresenta vantagens, limitações e cenários mais adequados para sua aplicação.
Nesta atividade, você atuará como consultor(a), sendo responsável por investigar, comparar e propor soluções arquiteturais para diferentes contextos.

1. Pesquisa e Fundamentação Teórica

Pesquise e explique, com suas próprias palavras:

• Arquitetura Monolítica
• Arquitetura em Microservices
• Arquitetura Orientada a Eventos (Event-Driven)
• SOA (Service-Oriented Architecture)

Para cada uma, apresente:

• Conceito
• Vantagens
• Desvantagens
• Exemplos reais de uso

2. Estudo de Cenários

Analise os cenários a seguir:

Cenário A – Startup em crescimento
Uma startup em rápida expansão precisa lançar funcionalidades com frequência, contando com uma equipe reduzida.
Cenário B – Sistema bancário
Sistema crítico que exige alta consistência, segurança e confiabilidade.
Cenário C – Plataforma de streaming
Sistema com milhões de usuários simultâneos, demandando alta escalabilidade e disponibilidade.

Para cada cenário:

• Indique a arquitetura mais adequada
• Justifique sua escolha com base em conceitos e referências
• Explique por que as demais arquiteturas são menos adequadas

3. Proposta Arquitetural

Escolha um dos cenários e:

• Proponha uma arquitetura distribuída que atenda às necessidades apresentadas
• Descreva:
o Componentes do sistema
o Forma de comunicação entre os serviços (ex: síncrona, assíncrona, APIs, mensageria, etc.)
• Elabore um diagrama representando a solução proposta

4. Análise Crítica

Responda de forma reflexiva:

• Quais foram as principais dificuldades na definição da arquitetura?
• Quais trade-offs foram identificados durante o processo?
• Existe uma “melhor” arquitetura de sistemas distribuídos? Justifique sua resposta

Referência:

MAPA - REDES - SISTEMAS DISTRIBUÍDOS - 52_2026.

----------------------------------------------------//----------------------------------------------------

Resposta para o Estudo de Arquiteturas de Sistemas Distribuídos

1) Pesquisa e Fundamentação Teórica

Arquitetura Monolítica

Conceito

A arquitetura monolítica é um modelo tradicional de desenvolvimento de software em que toda a aplicação é construída como um único sistema integrado. Nesse modelo, interface, regras de negócio e acesso a dados fazem parte da mesma base de código e são implantados juntos.

Normalmente, aplicações monolíticas utilizam um único banco de dados e possuem forte acoplamento entre os módulos internos. Apesar disso, ainda é amplamente utilizada devido à sua simplicidade inicial de desenvolvimento.

Vantagens

Estrutura simples de desenvolver e implantar.
Facilidade na comunicação interna entre módulos.
Menor complexidade operacional.
Processo de testes mais centralizado.
Boa opção para projetos pequenos ou equipes reduzidas.

Desvantagens

Dificuldade de escalabilidade parcial.
Alto acoplamento entre componentes.
Atualizações podem impactar todo o sistema.
Crescimento da aplicação aumenta a complexidade de manutenção.
Deploys tornam-se mais arriscados conforme o sistema evolui.

Exemplos reais de uso

Sistemas ERP tradicionais.
Sistemas acadêmicos institucionais.
Aplicações legadas corporativas.
Primeiras versões de plataformas como Facebook e Twitter.

Arquitetura em Microservices

Conceito

A arquitetura de microservices divide a aplicação em diversos serviços independentes, cada um responsável por uma funcionalidade específica do negócio. Esses serviços se comunicam por APIs ou mensageria e podem ser desenvolvidos, implantados e escalados separadamente.

Cada microserviço possui autonomia tecnológica e normalmente gerencia seu próprio banco de dados.

Vantagens

Alta escalabilidade.
Independência entre equipes e serviços.
Facilidade de manutenção e atualização.
Melhor tolerância a falhas.
Possibilidade de utilizar diferentes tecnologias em cada serviço.

Desvantagens

Maior complexidade arquitetural.
Necessidade de monitoramento avançado.
Comunicação distribuída aumenta latência.
Gestão de consistência de dados torna-se mais complexa.
Requer maturidade DevOps e automação.

Exemplos reais de uso

Netflix.
Amazon.
Uber.
Spotify.

Arquitetura Orientada a Eventos (Event-Driven)

Conceito

A arquitetura orientada a eventos baseia-se na produção e consumo de eventos. Em vez de comunicação direta entre serviços, componentes reagem a acontecimentos do sistema, como criação de pedidos, pagamentos ou atualizações de usuários.

Os eventos normalmente são distribuídos por brokers de mensageria, como Apache Kafka ou RabbitMQ.

Vantagens

Baixo acoplamento entre serviços.
Alta escalabilidade.
Processamento assíncrono eficiente.
Melhor capacidade de integração entre sistemas.
Alta responsividade em ambientes distribuídos.

Desvantagens

Maior dificuldade de rastreamento de processos.
Complexidade de monitoramento e depuração.
Possibilidade de inconsistência eventual.
Curva de aprendizado mais elevada.
Dependência de infraestrutura de mensageria.

Exemplos reais de uso

Sistemas de streaming.
Plataformas de e-commerce.
Sistemas financeiros de processamento em tempo real.
Aplicações IoT.

SOA (Service-Oriented Architecture)

Conceito

SOA (Arquitetura Orientada a Serviços) é um modelo arquitetural baseado na reutilização de serviços corporativos padronizados. Os serviços são compartilhados entre diferentes aplicações e geralmente integrados por meio de um barramento de serviços (ESB).

O foco principal do SOA é a interoperabilidade entre sistemas corporativos heterogêneos.

Vantagens

Reutilização de serviços.
Integração entre sistemas legados.
Padronização corporativa.
Facilidade de interoperabilidade.
Centralização de governança.

Desvantagens

Dependência do ESB pode gerar gargalos.
Maior complexidade de governança.
Menor flexibilidade comparada a microservices.
Custos elevados de implementação.
Pode gerar forte dependência organizacional.

Exemplos reais de uso

Grandes bancos.
Sistemas governamentais.
Integrações corporativas entre ERPs.
Ambientes empresariais com múltiplos sistemas legados.

2. Estudo de Cenários

Cenário A: Startup em Crescimento

Arquitetura mais adequada

Arquitetura em Microservices.

Justificativa

Startups em crescimento necessitam lançar funcionalidades rapidamente e adaptar-se constantemente às mudanças do mercado. A arquitetura de microservices permite que diferentes partes do sistema sejam desenvolvidas e implantadas independentemente, aumentando a agilidade das entregas.

Além disso, mesmo com equipes pequenas, a modularização facilita manutenção futura e escalabilidade gradual da plataforma.

Outro ponto importante é que microservices favorecem integração contínua (CI/CD), permitindo ciclos rápidos de atualização sem indisponibilizar todo o sistema.

Por que as demais arquiteturas são menos adequadas?

 Monolítica

Apesar da simplicidade inicial, torna-se limitada conforme o crescimento da aplicação. O aumento do acoplamento dificulta manutenção e evolução contínua.

SOA

Possui estrutura corporativa mais pesada, exigindo maior governança e infraestrutura, o que normalmente não é compatível com startups enxutas.

Event-Driven

Embora escalável, pode adicionar complexidade desnecessária em fases iniciais do negócio, principalmente no gerenciamento de eventos e monitoramento distribuído.

Cenário B: Sistema Bancário

Arquitetura mais adequada

SOA (Service-Oriented Architecture).

Justificativa

Sistemas bancários exigem alta confiabilidade, segurança, rastreabilidade e integração entre diversos sistemas corporativos. O SOA oferece forte governança, padronização de serviços e integração consistente entre aplicações críticas.

Além disso, bancos frequentemente operam sistemas legados que precisam comunicar-se de forma estável e segura, característica fortemente atendida pela arquitetura SOA.

O uso de ESB também facilita auditoria, controle transacional e gerenciamento centralizado.

Por que as demais arquiteturas são menos adequadas?

Monolítica

Dificulta evolução e integração com múltiplos sistemas corporativos.

Microservices

Apesar de escalável, pode aumentar significativamente a complexidade de consistência transacional e segurança distribuída.

Event-Driven

A consistência eventual presente nesse modelo pode não ser adequada para operações financeiras críticas que exigem consistência imediata.

Cenário C: Plataforma de Streaming

Arquitetura mais adequada

Arquitetura Orientada a Eventos (Event-Driven) combinada com Microservices.

Justificativa

Plataformas de streaming lidam com milhões de acessos simultâneos e necessitam processar eventos em tempo real, como reprodução de mídia, recomendações, autenticação, métricas e distribuição de conteúdo.

A arquitetura orientada a eventos permite processamento assíncrono altamente escalável, enquanto microservices possibilitam divisão funcional eficiente do sistema.

Esse modelo melhora disponibilidade, tolerância a falhas e capacidade de expansão horizontal.

Por que as demais arquiteturas são menos adequadas? 

Monolítica

Não suporta adequadamente escalabilidade massiva e alta disponibilidade.

SOA

Embora permita integração, possui overhead maior e menor flexibilidade para cargas altamente dinâmicas.

Apenas Microservices

Sem eventos, a comunicação síncrona excessiva pode gerar gargalos em cenários de grande volume de usuários simultâneos. 

3) Proposta Arquitetural

Cenário Escolhido

Cenário C: Plataforma de Streaming.

Arquitetura Proposta

A solução proposta utiliza uma combinação de microservices com arquitetura orientada a eventos, visando garantir:

Alta escalabilidade.
Processamento distribuído.
Alta disponibilidade.
Resiliência.
Baixa latência.

Componentes do Sistema

API Gateway

Responsável por centralizar requisições externas, autenticação e roteamento para os serviços internos.

Serviço de Autenticação

Gerencia login, tokens JWT e controle de acesso.

Serviço de Catálogo

Responsável pelas informações de filmes, séries e conteúdos disponíveis.

Serviço de Streaming

Gerencia distribuição de mídia e comunicação com CDN.

Serviço de Recomendação

Processa histórico do usuário para sugerir conteúdos personalizados.

Serviço de Monitoramento

Coleta métricas, logs e eventos operacionais.

Broker de Mensagens

Utilização de Apache Kafka ou RabbitMQ para troca assíncrona de eventos.

Banco de Dados Distribuído

Cada microserviço possui banco de dados próprio, reduzindo acoplamento.

Forma de Comunicação

Comunicação síncrona

APIs REST entre cliente e API Gateway.
Comunicação direta em operações críticas e imediatas.

Comunicação assíncrona

Eventos distribuídos via Kafka/RabbitMQ.
Processamento desacoplado de reprodução, métricas e recomendações.

Diagrama da Solução:



4) Análise Crítica

Principais dificuldades na definição da arquitetura

A principal dificuldade foi equilibrar escalabilidade, desempenho, segurança e complexidade operacional. Em sistemas distribuídos, aumentar a flexibilidade frequentemente implica maior dificuldade de gerenciamento.

Outro desafio importante foi escolher entre consistência forte e desempenho. Arquiteturas altamente distribuídas tendem a trabalhar com consistência eventual, o que pode não ser aceitável em todos os contextos.

Também foi necessário considerar fatores organizacionais, como maturidade técnica da equipe, custos operacionais e capacidade de monitoramento.

Trade-offs identificados

Os principais trade-offs observados foram:

Simplicidade vs Escalabilidade

Arquiteturas monolíticas são mais simples inicialmente, porém limitadas em crescimento.

Consistência vs Disponibilidade

Sistemas distribuídos frequentemente precisam abrir mão de consistência imediata para garantir alta disponibilidade.

Baixo acoplamento vs Complexidade

Microservices e Event-Driven reduzem acoplamento, mas aumentam dificuldade operacional.

Desempenho vs Governança

SOA oferece forte controle corporativo, porém com maior overhead e menor flexibilidade.

Existe uma “melhor” arquitetura de sistemas distribuídos?

Não existe uma arquitetura universalmente melhor. A escolha depende diretamente dos objetivos do sistema, do contexto organizacional e dos requisitos não funcionais.

Cada arquitetura resolve problemas específicos:

Monolítica prioriza simplicidade.
Microservices priorizam escalabilidade e independência.
Event-Driven prioriza desacoplamento e processamento assíncrono.
SOA prioriza integração corporativa e governança.

Portanto, a arquitetura ideal é aquela que melhor atende às necessidades técnicas e estratégicas do cenário analisado, considerando custos, equipe, manutenção e crescimento futuro.

Referências

FOWLER, Martin. Microservices. Disponível em: Martin Fowler. Acesso em: 26 maio 2026.
IBM. Service-Oriented Architecture (SOA). IBM Documentation. Acesso em: 26 maio 2026.
AMAZON WEB SERVICES (AWS). What is Event-Driven Architecture?. AWS Documentation. Acesso em: 26 maio 2026.
MICROSOFT. Monolithic vs. Microservices Architecture Styles. Microsoft Learn. Acesso em: 26 maio 2026.
RED HAT. What are Microservices?. Red Hat Documentation. Acesso em: 26 maio 2026.
NEWMAN, Sam. Building Microservices. 2. ed. Sebastopol: O’Reilly Media, 2021.
RICHARDSON, Chris. Microservices Patterns. Greenwich: Manning Publications, 2018.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 4. ed. Boston: Addison-Wesley, 2021.