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.
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:
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.
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
1. Pesquisa e Fundamentação Teórica
• Arquitetura em Microservices
• Arquitetura Orientada a Eventos (Event-Driven)
• SOA (Service-Oriented Architecture)
• Vantagens
• Desvantagens
• Exemplos reais de uso
2. Estudo de Cenários
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.
• Justifique sua escolha com base em conceitos e referências
• Explique por que as demais arquiteturas são menos adequadas
3. Proposta Arquitetural
• 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
• 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
• Quais trade-offs foram identificados durante o processo?
• Existe uma “melhor” arquitetura de sistemas distribuídos? Justifique sua resposta
Referência:
----------------------------------------------------//----------------------------------------------------
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.
Cada microserviço possui autonomia tecnológica e normalmente gerencia seu próprio banco de dados.
Os eventos normalmente são distribuídos por brokers de mensageria, como Apache Kafka ou RabbitMQ.
O foco principal do SOA é a interoperabilidade entre sistemas corporativos heterogêneos.
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.
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.
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.
Comunicação direta em operações críticas e imediatas.
Processamento desacoplado de reprodução, métricas e recomendações.
Diagrama da Solução:
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.
Cada arquitetura resolve problemas específicos:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.

