3.0 Introdução à Parte 3: Sistemas
A arquitetura é o conjunto de decisões que são caras de reverter. Como você divide um sistema em partes? Como essas partes conversam entre si? Como os dados são modelados? E como o todo se comporta sob carga e sob falha? A Parte 3 trata de tomar essas decisões de propósito. Numa equipe pequena, a arquitetura pode viver em algumas cabeças e evoluir à medida que se avança. Numa grande organização (centenas de engenheiros, dezenas de equipes, sistemas que sobreviverão às carreiras das pessoas que os constroem), a arquitetura se torna aquilo que mantém todos coordenados. Quando é clara, as equipes se movem de forma independente sem colidir. Quando é vaga, cada dependência entre equipes vira uma negociação e cada incidente vira um projeto de arqueologia.
O que está em jogo é maior em empresas e governo. Um motor de impostos, uma plataforma de benefícios, um prontuário nacional de saúde ou o livro-razão central de um banco são de longa vida, fortemente regulamentados, compartilhados entre departamentos e sujeitos à prestação de contas ao público. As decisões que você toma hoje sobre acoplamento, propriedade de dados e atributos de qualidade restringirão o que é possível por uma década ou mais. Reguladores e auditores esperam cada vez mais uma arquitetura documentada e defensável, com evidência real de que confiabilidade, segurança, privacidade e durabilidade foram projetadas desde o início e não remendadas depois. As falhas que viram manchete são falhas arquiteturais: portais que cedem no dia do lançamento, sistemas de declaração que estouram o tempo no prazo final, migrações que perdem ou contam em dobro registros.
Esta parte começa pelos fundamentos duradouros, passa pelas escolhas estruturais concretas, depois pelas realidades da distribuição, dos dados e da escala e termina com o problema mais difícil que a maioria das grandes organizações de fato enfrenta: modernizar os sistemas que já operam. O fio que amarra tudo: boa arquitetura é uma série de compromissos conscientes, não um padrão da moda.
Capítulos desta parte
3.1 Fundamentos de arquitetura. As ferramentas duradouras que sobrevivem à moda tecnológica: atributos de qualidade (os “-ilidades”), requisitos arquiteturalmente significativos, funções de aptidão (testes automatizados que protegem uma qualidade arquitetural escolhida) e arquitetura evolutiva, documentação leve com o modelo C4 (diagramas de arquitetura aninhados em quatro níveis de zoom) e o arc42 (um modelo de documentação de arquitetura) e análise estruturada de compromissos.
3.2 Estilos e padrões arquiteturais. Um panorama das principais formas de sistema, do monólito aos microsserviços, às arquiteturas orientadas a eventos com CQRS (Command Query Responsibility Segregation, que separa os modelos de leitura dos de escrita) e event sourcing (guardar o estado como um log de eventos somente de acréscimo), à malha de serviços (uma camada de infraestrutura dedicada à comunicação entre serviços) e gateways, ao serverless e à arquitetura hexagonal e limpa, com orientação sobre quando cada uma se encaixa, enquadrada pela lei de Conway (os sistemas tendem a espelhar a estrutura de comunicação da organização que os constrói).
3.3 Sistemas distribuídos. As verdades duras que aparecem no momento em que você cruza uma fronteira de rede (redes não confiáveis, falha parcial, ausência de relógio compartilhado) e as defesas padrão: raciocínio de consistência, idempotência (tornar uma operação segura de repetir), novas tentativas com recuo, disjuntores (que param de chamar uma dependência que falha), sagas (sequências de transações locais com etapas compensatórias de desfazer) e observabilidade distribuída.
3.4 Arquitetura de dados e armazenamento. Como os dados são modelados, armazenados, mantidos consistentes e servidos rápido em escala: os principais paradigmas de armazenamento e quando usar cada um, a persistência poliglota (usar vários armazenamentos de dados especializados num só sistema), a evolução e a migração de esquemas, o cache e as CDNs (redes de distribuição de conteúdo) e as transações e a concorrência sob carga.
3.5 Escalabilidade, desempenho e resiliência. Três qualidades distintas projetadas desde o início e não adaptadas depois: escalamento horizontal e vertical, ausência de estado e sharding (dividir os dados entre máquinas por uma chave), balanceamento de carga e escalamento automático, orçamentos de desempenho, padrões de resiliência e engenharia do caos e recuperação de desastres multirregional enquadrada pelo RTO (objetivo de tempo de recuperação) e pelo RPO (objetivo de ponto de recuperação).
3.6 Modernização de sistemas legados. Os padrões incrementais que realmente funcionam, a figueira-estranguladora (fazer um sistema novo crescer em volta do antigo até o antigo poder ser aposentado) e a ramificação por abstração (substituir um componente atrás de uma interface na linha principal de desenvolvimento), mais a avaliação de risco do legado, a custódia de mainframes e de COBOL (Common Business-Oriented Language), a migração de dados e a execução em paralelo e como resistir à tentação da grande reescrita que produz os fracassos mais caros do campo.
3.7 Manutenção de software. A fase dominante da vida do software: manutenção corretiva, adaptativa, perfectiva e preventiva, compreensão de programas e reengenharia e projetar para a manutenibilidade para que sistemas de longa vida continuem acessíveis de mudar.
3.8 Interoperabilidade e padrões abertos. Projetar sistemas para interoperar por padrões abertos em vez de integrações sob medida: interoperabilidade técnica, sintática e semântica, padrões de domínio como o FHIR na saúde e o custo do aprisionamento proprietário.
3.9 Engenharia de sistemas. Engenharia de sistemas complexos de ponta a ponta, muitas vezes combinando software, hardware, pessoas e processos: ciclo de vida, alocação e rastreabilidade de requisitos, interfaces, integração e verificação e validação.
3.10 Sistemas embarcados e de tempo real. Software para dispositivos sob restrições severas: comportamento em tempo real e determinismo, um RTOS ou firmware direto no hardware, memória e energia limitadas, interação com o hardware e normas críticas para a segurança.
3.11 Arquitetura na nuvem. Projetar para a nuvem em vez de simplesmente transplantar um centro de dados: modelos de serviço e serverless, regiões e zonas de disponibilidade como domínios de falha, o modelo de responsabilidade compartilhada, os compromissos entre serviços gerenciados e aprisionamento, multinuvem e híbrido quando justificam sua complexidade e um design consciente de custos e bem arquitetado.
3.12 Arquitetura orientada a eventos e mensageria. Construir sistemas que se comunicam produzindo e reagindo a eventos: filas versus fluxos duráveis, coreografia versus orquestração, event sourcing e CQRS onde merecem seu lugar, sagas para transações distribuídas, garantias de entrega e idempotência e os padrões que mantêm confiáveis os fluxos assíncronos.
3.13 Redes e conectividade. As redes com que uma pessoa engenheira de aplicações de fato lida: DNS, TCP e a evolução do HTTP, terminação de TLS, balanceamento de carga e proxies reversos, entrega de conteúdo e borda, descoberta de serviços e malha de serviços e os tempos limite, novas tentativas e disjuntores que tornam suportável a falta de confiabilidade da rede.
3.14 Multilocação e arquitetura SaaS. Atender muitos clientes a partir de uma só instância de software sem deixar que se vejam nem se esgotem uns aos outros: o espectro entre isolamento e eficiência, o particionamento de dados, as cotas por locatário contra os vizinhos barulhentos, o ciclo de vida do locatário e a atribuição de custos.
3.15 Cache e entrega de conteúdo. Trocar um pouco de obsolescência por grandes ganhos em latência, carga e custo ao longo da hierarquia de cache (cliente, borda e CDN, proxy reverso, aplicação e armazenamento de dados), tratando a invalidação de cache e a proteção contra debandadas como design de primeira classe.
3.16 Gateways de API e malha de serviços. Tratar o tráfego norte-sul num gateway de API (roteamento, autenticação, limitação de taxa, composição) e o tráfego leste-oeste por uma malha de serviços (TLS mútuo, deslocamento de tráfego, novas tentativas, observabilidade) e decidir quando uma malha justifica sua complexidade.
3.17 Busca e recuperação de informação. Tratar a busca como um sistema de primeira classe, do índice invertido e da classificação de relevância à compreensão de consultas, às facetas e à recuperação vetorial e híbrida, com avaliação real de relevância em vez de palpite.
Como estes capítulos se relacionam
Os capítulos se constroem uns sobre os outros em ordem. O capítulo 3.1 dá o vocabulário (atributos de qualidade e análise de compromissos) que todo capítulo posterior usa. Os “-ilidades” que ele nomeia são exatamente o que os capítulos 3.4 e 3.5 tornam concreto. O capítulo 3.2 transforma esses fundamentos em escolhas estruturais, e os estilos mais distribuídos que ele endossa (microsserviços, orientado a eventos, malha de serviços) trazem os custos que o capítulo 3.3 ensina a gerenciar. Os capítulos 3.3, 3.4 e 3.5 se apoiam intensamente uns nos outros: a distribuição força as decisões de consistência e durabilidade da arquitetura de dados e, juntas, a distribuição e os dados moldam que escalabilidade e resiliência vocês conseguem de fato alcançar. O capítulo 3.6 fecha o ciclo, porque a maioria das grandes organizações não está construindo sobre uma página em branco: está evoluindo sistemas de registro que restringem toda escolha que os capítulos anteriores descrevem.
A Parte 3 também alcança o exterior. O capítulo 3.2 se apoia nos princípios de design e no Domain-Driven Design do capítulo 2.2 para encontrar boas fronteiras de serviço. As disciplinas operacionais que mantêm esses sistemas funcionando moram na Parte 9: a engenharia de confiabilidade de sites (capítulo 9.1) e a observabilidade (capítulo 9.2) são onde a resiliência arquitetural é provada em produção. As propriedades de segurança e de privacidade que os reguladores exigem são projetadas aqui mas detalhadas na Parte 4, e as práticas de plataforma e de entrega da Parte 8 decidem se uma arquitetura pode de fato ser entregue e operada por muitas equipes ao mesmo tempo.