Executando verificação de segurança...
1

System Design descomplicado: conceitos que fazem a cidade funcionar

🧭 Esta é a edição #7 da minha newsletter Logbook for Devs, um logbook dev com relatos de uma jornada, aprendizados e reflexões.

Se curtir, assina lá pra acompanhar as próximas.


Imagine que você está construindo uma cidade. Cada serviço tem sua função: o banco gerencia dinheiro, o correio entrega cartas, o hospital cuida da saúde. Mas sem organização, a cidade vira um caos. No mundo do desenvolvimento, o System Design é essa engenharia urbana que mantém tudo funcionando de forma eficiente.

E pra isso, existem padrões que fazem toda a diferença:

👀 CQRS (Command Query Responsibility Segregation)

Separar leitura e escrita melhora a performance e evita gargalos. Imagine um restaurante onde um garçom anota pedidos (escrita) e outro busca informações do cardápio (leitura). Assim, um não atrapalha o outro.

👀 Saga Pattern (Gerenciamento de transações distribuídas)

Já tentou cancelar um pedido online e só parte do processo foi desfeita? O Saga Pattern impede isso, garantindo que, se uma etapa falhar, tudo volte ao estado inicial. Como numa cozinha, onde se um prato queima, o pedido inteiro é refeito ou cancelado.

👀 API Gateway + Service Discovery

Ao invés de cada microserviço ter que saber o endereço exato dos outros, eles se comunicam por um "roteador central" que direciona as requisições. Como num aeroporto, onde os painéis informam para onde cada voo deve ir, sem precisar perguntar um por um.

👀 Event-Driven Architecture

Imagine um show onde cada luz acende ao som de um instrumento. É assim que funciona a comunicação baseada em eventos: ao invés de serviços perguntarem constantemente "tem algo novo?", eles reagem quando algo acontece.

👀 Idempotência & Retry Pattern

Se você faz um pagamento e aperta "confirmar" duas vezes, deveria ser cobrado apenas uma, certo? O sistema precisa garantir que a ação repetida não tenha efeito colateral. Isso evita que processos críticos se tornem um pesadelo.

👀 Real-Time Data: Polling vs SSE vs WebSockets

Cada método tem seu uso ideal:

  • Polling é como perguntar "já chegou?" o tempo todo. Cansa...
  • SSE é como um SMS que chega quando há novidade. Simples e eficiente.
  • WebSockets são como uma ligação: comunicação bidirecional constante, ideal para chats e games.

Resumo:

Precisa de performance? Separe leitura e escrita (CQRS).
Tem múltiplas etapas críticas? Use Saga Pattern.
Precisa de escalabilidade? API Gateway + Service Discovery são chave.
Quer comunicação assíncrona? Arquitetura baseada em eventos.
Transações críticas? Idempotência e retry são essenciais.
Dados em tempo real? Escolha entre SSE, WebSockets ou polling.

System Design não é só sobre código, mas sobre construir sistemas que resistem ao tempo. Se tivesse que escolher apenas um desses padrões pro seu projeto hoje, qual seria?


🌊 Marés da semana


📦 Treasure - Good Stuff


⚓ Se chegou até aqui, já deu pra sentir o clima de bordo.

Essa é uma das entradas do meu Logbook for Devs —
onde registro ideias, reflexões técnicas e ferramentas que cruzam meu caminho na jornada dev.

Toda terça e quinta tem uma nova anotação de rota, com marés atualizadas e tesouros recém-descobertos.

⛵ Quer seguir viagem comigo?
Embarque aqui.

Carregando publicação patrocinada...
4

Precisa de performance? Separe leitura e escrita (CQRS).

Cansei de ver app com nem 10k/req/min usando CQRS em uma única instância de banco de dados. Essa é a melhor técnica para triplicar o tempo de dev quando não precisa ser aplicada hahaha