Untitled Flashcards Set

Arquitetura vs Design

Obs: existem pontos de vista diferentes

Arquitetura: escopo global (restrições de alto nível, atributos de qualidade)

Design: escopo local (como implementar os componentes)

→ Sempre que se fala de arquitetura também se fala de design, mas nem sempre que se fala de design se fala de arquitetura

Sustentabilidade

  • Software precisa acompanhar a evolução do negócio.

  • Quanto mais tempo o software ficar no ar, mais retorno gera.

Pilares da Arquitetura de Software

  • Estruturação

    • Fácil evolução, como componentizar os objetivos de negócio

  • Componentização

  • Relacionamento entre sistemas

  • Governança: documentação, regras, definições, não necessitar de uma pessoa

Requisitos Arquiteturais (RAs)

→ Com os modelos de squad, os requisitos ficaram mais flexíveis e implícitos

Define as regras de desenvolvimento

  • Tipos de Requisitos

    • Performance

    • Armazenamento de dados

    • Escalabilidade (horizontal, vertical, load balancer)

    • Segurança

    • Auditoria (eg. logar acessos e operações)

    • Marketing (eg. tracking de dados)

Características Arquiteturais

Checklist de características para se pensar quando for desenvolver software:

  • Características Operacionais

    • Disponibilidade

    • Recuperação de desastres

    • Performance

    • Recuperação (backup)

    • Confiabilidade e segurança

    • Robustês (consegue escalar se necessário)

    • Escalabilidade

  • Características Estruturais

    • Configurável (trocar chaves, senhas, etc)

      • Deve ser fácil mudar de ambiente (dev → sandbox → prod)

    • Extensibilidade

      • Deve ser pensado para crescer

      • Deve ser fácil adicionar vendors (message brokers, banco de dados, api, etc) e lógica (Open/Close do SOLID)

    • Fácil instalação

      • Padronização de ambiente (containers)

      • Configurável

      • Se preocupar com dependências (elastic search, tópicos do kafka, etc)

    • Reuso de componentes

    • Internacionalização

      • Front-End: layout, cultura

      • Back-End: moeda, políticas de pagamento

    • Fácil manutenção

      • Usar testes

    • Portabilidade

      • Diminuir a dependência de vendors

    • Fácil suporte (logs, debugging)

  • Características Cross-Cutting

    • Acessibilidade

    • Processo de rentenção e recuperação de dados

      • Tempo que os dados serão mantidos

    • Autenticação e Autorização

    • Partes Legais

    • Privacidade (LGPD)

    • Segurança

    • Usabilidade (back e front)

Perspectiva de Performance

Performance é o desempenho que um software possui para completar um determinado workload

→ Ter um software escalável é diferente de ter um software performático

  • Métricas para medir performance

    • Latência ou “response time”

      • Normalmente medida em milliseconds

      • Afetada pelo processamento da aplicação, rede e chamadas externas

    • Throughput

      • Quanto de requisição o software consegue aguentar

      • Ligado a latência

  • Razões para baixa performance

    • Processamento ineficiente

      • Lógica por trás do software (algoritmos, queries, frameworks)

      • Uso de um banco de dados correto

    • Recursos computacionais limitados (vertical, horizontal)

      • Escala da capacidade computacional (CPU, Disco, Memória) - vertical

      • Caching

        • → Pode ser exclusivo (local) ou compartilhado (centralizado)

        • Cache na borda / Edge computing (CloudFlare / Akamai)

          • Mais próximo ao usuário

          • Evita requisição chegar até o Cloud Provider

          • Arquivos estáticos / CDN (Content Delivery Network)

          • Origin (provider) → Midwest (espalhamento) → Edge (usuário)

        • Dados estáticos

        • Páginas web

        • Funções internas

          • Algoritmos pesados

          • Acesso ao db

        • Objetos

    • Trabalhar de forma bloqueante / Acesso serial a recursos (locks, sync)

      • Concorrência e paralelismo

        • Concorrência é sobre lidar com muitas coisas ao mesmo tempo. Paralelismo é fazer muitas coisas ao mesmo tempo (Rob Pyke - um dos criadores do Go)

    Perspectiva de Escalabilidade

    Escalabilidade é a capacidade de sistemas suportarem o aumento (ou a redução) dos workloads incrementando (ou reduzindo) o custo em menor ou igual proporção

    → Escalabilidade vs Performance

    Enquanto performance tem o foco em reduzir a latência e aumentar o throughput, a escalabilidade visa termos a possibilidade de aumentar ou diminuir o throughput adicionando ou removendo a capacidade computacional

  • Descentralização

    • → Uma máquina específica pode ser destruída ou criada a qualquer momento

    • Disco efêmero (eg. usar bucket s3 ao invés do disco da máquina)

    • Servidor de aplicação vs Servidor de assets (eg. bucket s3)

    • Cache centralizado (compartilhado)

    • Sessões (estado) centralizadas em um servidor (db)

  • Escalando banco de dados

    • Aumentar recurso compuacional

    • Dividir banco para escrita e leitura

    • Shards horizontais para leitura

    • Shard por particionamento

    • Otimizar queries

      • APM (Application Performance Monitor)

      • Explain

      • Indexar

      • CQRS (Command Query Responsibility Segregation)

  • Proxy reverso (Procurador)

    • É diferente de load balancer

    • Pode levar para servers com apps diferentes

    • Exemplos:

      • Nginx

      • HAProxy (HA = High Avaibility)

      • Traefik

      • Kong, API Gateway (baseado no Nginx)

Perspectiva de Resiliência

Resiliência é um conjunto de estratégias adotadas intencionalmente para a adaptação de um sistema quando uma falha ocorre.

Proteger e ser protegido

  • Um sistema não pode ser egoísta ao ponto de realizar mais requisições em um sistema que está falhando

  • Um sistema lento pode ser pior que um fora do ar (efeito dominó A → B → C = C lento gera A lento)

Health check

  • Um sistema que não está saudável possui chance de se recuperar caso o tráfego pare de ser direcionado a ele temporariamente (self healing)

  • Verificar diferentes componentes para gerar o health check (não apenas retornar 200 caso esteja on)

Rate Limiting

  • Saber quanto de carga um sistema pode suportar (orçamento, teste de stress, quantidade de máquinas)

  • Limitar requisições baseado no nível de criticidade do cliente

Circuit breaker

  • Protege o sistema fazendo com que as requisições sejam negadas

  • Objetivo é impedir efeito dominó e aplicar self healing

  • Circuito aberto = requisições não chegam no sistema

  • Circuito meio aberto = Permite uma quantidade limitada para verificar saúde

  • Circuito fechado = requisição chegam no sistema normalmente

  • Service mesh já implementa circuit breaker

API Gateway

  • “Portaria das APIs" - Ex. usuário não autenticado

  • Implementa políticas de Rate Limiting, Health Check, etc

Service Mesh

  • Controla o tráfego de rede

  • Evita implementações de proteção pelo próprio sistema (retry, rate limiting, circuit breaker, etc)

  • mTLS - Criptografa comunicação entre serviços evitando “man in the middle”

Trabalhar de forma assíncrona

  • Aguardar na fila

  • Evita perda de dados

  • Message broker / sistema de stream (fila)

Retry

  • Exponential backoff (esperar de forma exponencial)

  • Exponential backoff - Jitter (adicionar ruído a cada tentativa)

Garantias de entrega: Kafka

  • Ack 0 → sem confirmação de recebimento

  • Ack 1 → confirmação de recebimento pelo líder

  • Ack -1 → confirmação de recebimento por todas (líder e seguidores)

→ Cada ponto percentual adicionado de resiliência aumenta o custo