Arquitetura de software 360 graus

Vamos analisar o conteúdo que será apresentado nessa seção.

Vamos analisar o modelo de sistemas orientados a eventos com um exemplo prático ilustrativo.

Sistemas reativos lidam com fluxos contínuos de dados, muitas vezes provenientes de sensores, logs, usuários ou sistemas distribuídos, e reagem a eles em tempo real.

Um monólito é uma aplicação estruturada como uma única unidade de implantação.
Todo o código , interface, lógica de negócio e acesso a dados são empacotados e executados como um único processo.

Service Oriented Architecture (SOA) é um estilo de arquitetura que organiza o sistema em serviços autônomos, projetados para expor funções de negócio de forma reutilizável e interoperável.

Microsserviços são um estilo arquitetural que organiza um sistema como um conjunto de serviços pequenos, autônomos e coesos, cada um responsável por um bounded context ou parte dele

Em uma arquitetura distribuída, diferentes serviços precisam cooperar para cumprir um fluxo de negócio. Essa cooperação acontece por meio de comunicação inter-serviços, que pode seguir dois paradigmas fundamentais: síncrono e assíncrono.

Cloud-native não é apenas rodar uma aplicação na nuvem. É projetar o sistema desde o início para lidar com falhas, crescer sob demanda, automatizar sua própria operação e ser monitorável em produção. Multi-tenant é um modelo onde um único sistema atende vários clientes (tenants) isoladamente.

Visão geral sobre o conteúdo da seção

Esses protocolos existem para garantir que múltiplos nós em um sistema distribuído concordem sobre um estado, valor ou decisão, mesmo diante de falhas de rede, latência ou queda de servidores.

Suportam a manutenção do estado distribuído, a detecção de nós inativos e a estabilidade de logs replicados. Eles são a camada que permite que algoritmos de consenso, coordenação e replicação funcionem sem divergências ou corrupção de estado.

Modelos de tempo e ordenação são camadas fundamentais para sistemas distribuídos, pois permitem inferir causalidade, determinar precedência lógica entre operações e evitar inconsistências quando não existe um relógio global confiável.

Nesta aula, demonstraremos os conceitos apresentados e que foram cobrados na tarefa. Você pode baixar a solução da própria tarefa ou dos recursos desta aula.

Visão geral sobre o conteúdo desta seção.

Estratégias de divisão de dados e persistência que impactam diretamente escalabilidade, throughput, latência, consistência e custos operacionais.

Em sistemas distribuídos, requisições nem sempre chegam na velocidade que o serviço consegue processar. Mesmo um sistema perfeitamente escalável eventualmente enfrenta saturação quando a taxa de chegada excede momentaneamente a taxa de processamento.

Em sistemas distribuídos, o estado pode mudar enquanto múltiplos componentes tentam atualizá-lo ou lê-lo ao mesmo tempo. A consequência óbvia são condições de corrida, inconsistências, leituras sujas, escrita perdida, ou comportamentos imprevisíveis quando falhas e retransmissões acontecem.

Implemente um mini sistema de processamento de pedidos que use particionamento fixo, batching de requisições e uma fila de atualização singular idempotente para manter o estado consistente sob concorrência.

Veremos uma possível resposta ao exercício dado.

Objetivo desta aula: criar a base conceitual para entender como sistemas distribuídos lidam com crescimento, falhas e mudanças.

Entender como sistemas distribuídos continuam funcionando mesmo quando partes falham, ficam lentas ou entram em sobrecarga.

Construir a capacidade de entender, explicar e operar sistemas distribuídos em produção.

O exemplo está disponível no GitHub: https://github.com/cleuton/rustingcrab/tree/main/code_samples/opentelemetry

Veremos o que é arquitetura de dados

Em sistemas distribuídos, uma única operação de negócio frequentemente atravessa múltiplos serviços, cada um com seu próprio banco de dados, tecnologia, linguagem e ciclo de vida.

Arquiteturas data-oriented partem de uma inversão importante de perspectiva: em vez de organizar o sistema primariamente em torno de serviços, APIs ou aplicações, o fluxo dos dados passa a ser o eixo central da arquitetura.

Data Mesh é uma abordagem arquitetural e organizacional que descentraliza a responsabilidade pelos dados, alinhando ownership aos domínios de negócio. Data Fabric é uma abordagem técnica que cria uma camada transversal de integração, descoberta, segurança e governança para dados distribuídos.

Em vez de um sistema chamar outro diretamente ou compartilhar banco de dados, ele publica eventos que representam fatos ocorridos no domínio.

Em arquiteturas data-oriented, governança não é um processo burocrático imposto depois que o sistema está pronto. Ela é um requisito estrutural que permite que múltiplos produtores e consumidores evoluam de forma independente sem quebrar o ecossistema.

Introdução à arquitetura de real-time systems

Comunicação em tempo real é um modelo de sistema em que o tempo de entrega do evento faz parte do significado da informação.

Escalar um sistema real-time significa escalar conexões ativas e fluxos de eventos simultâneos, não apenas requisições por segundo.

Em sistemas real-time, como WebSockets, Server-Sent Events ou streams, a conexão pode durar minutos ou horas.

Sistemas real-time modernos são construídos a partir de event streaming, usando Kafka como backbone, explorando padrões de integração com clientes, principais casos de uso e os trade-offs arquiteturais inevitáveis entre simplicidade, custo e experiência do usuário

Vamos a uma demonstração em Python com React de SSE.

Arquiteturas em nuvem representam desafios para as empresas, assim como projetos SaaS.

Arquitetura em cloud existe para tornar a aplicação viável sob variabilidade. Onde não há variabilidade relevante, cloud tende a adicionar custo cognitivo e operacional sem retorno.

Evolução arquitetural é um processo contínuo realizado com sistemas em produção, especialmente em ambientes de nuvem.

Métricas e governança técnica existem para tornar a qualidade arquitetural observável, verificável e controlável ao longo do tempo, usando dados objetivos e automação.

Métricas arquiteturais existem para tornar visível o custo estrutural de evoluir um sistema ao longo do tempo.

Governança prática trata de como decisões arquiteturais deixam de existir apenas na cabeça das pessoas ou em documentos esquecidos e passam a ser mecanismos técnicos ativos, verificáveis e executáveis.