// backend.lumi

Backend

APIs e serviços que sustentam produto em produção — arquitetura que escala sem surpresas.

O backend é a fundação invisível sobre a qual toda experiência de produto é construída — quando ele falha, tudo falha. Projetamos sistemas backend com clareza de limites de domínio, APIs bem documentadas e contratos explícitos entre serviços, porque sistemas distribuídos mal delimitados são a principal fonte de dívida técnica em organizações de tecnologia em crescimento. Nossa abordagem combina Clean Architecture, Domain-Driven Design e padrões de microsserviços para construir sistemas que novos engenheiros conseguem entender, testar e evoluir com segurança.

Avaliar meu stack →Ver serviços Lumi
// o que é

Desenvolvimento backend é a disciplina de engenharia responsável pela lógica de negócio, persistência de dados, integração entre sistemas e exposição de APIs que sustentam aplicações de produto. A evolução de monolitos para microsserviços transformou a complexidade de dentro dos sistemas (complexidade de código) para entre os sistemas (complexidade de rede e consistência distribuída), exigindo domínio de padrões como event sourcing, CQRS e sagas para gerenciar estado em ambientes distribuídos. Domain-Driven Design (Evans, 2003) oferece o vocabulário e as ferramentas para delimitar bounded contexts, definir linguagem ubíqua e separar o modelo de domínio dos detalhes de infraestrutura, permitindo que sistemas complexos cresçam sem perder coerência. Clean Architecture (Martin, 2017) complementa o DDD ao estabelecer a regra de dependência — camadas internas não conhecem camadas externas — garantindo que a lógica de negócio seja testável independentemente de frameworks, bancos de dados e interfaces.

// tecnologias

O que compõe a stack de Backend

Linguagem / EcosistemaPython

Linguagem de alta produtividade com ecossistema rico em data, ML e web (FastAPI, Django, Flask), dominante em backends de dados e APIs de ML serving.

Linguagem / RuntimeNode.js

Runtime JavaScript orientado a eventos com I/O não bloqueante, ideal para APIs de alta concorrência, BFFs e serviços de integração em tempo real.

Linguagem / PerformanceGo

Linguagem compilada com goroutines para concorrência leve, usada em serviços de alto throughput, CLIs e infraestrutura onde performance e simplicidade operacional são prioritários.

Linguagem / EnterpriseJava

Linguagem de alto ecossistema enterprise com Spring Boot como framework dominante, forte em sistemas financeiros, ERP e microserviços com requisitos de tipagem estrita e longevidade.

Linguagem / SistemasRust

Linguagem de sistemas com garantias de segurança de memória em tempo de compilação, usada em backends críticos de performance, WebAssembly e infraestrutura onde zero-cost abstractions são necessárias.

Plataforma / Enterprise.NET

Plataforma Microsoft com C# como linguagem principal, forte integração com Azure, ASP.NET Core para APIs de alta performance e ecossistema maduro para sistemas corporativos.

// arquitetura

Padrões e abordagens para Backend

01

Clean Architecture / Hexagonal Architecture

Organiza o código em camadas concêntricas onde a regra de dependência aponta sempre para dentro — entidades de domínio no centro, casos de uso ao redor, adaptadores na borda — garantindo que a lógica de negócio seja completamente independente de frameworks, banco de dados e interfaces externas. Isso permite trocar o banco de dados, o framework web ou o protocolo de API sem tocar na lógica de negócio, e testar casos de uso com mocks simples sem subir infraestrutura real.

Ideal paraSistemas com lógica de negócio complexa que precisam de alta cobertura de testes e longevidade de código além do ciclo de vida dos frameworks
02

Event-Driven Architecture com CQRS

Separa comandos (intenções de mudar estado) de queries (consultas de estado) em modelos diferentes — CQRS — e usa eventos de domínio para propagar mudanças entre serviços de forma assíncrona e desacoplada. Permite otimizar modelos de leitura e escrita independentemente, escalar partes do sistema separadamente e construir audit trails completos com event sourcing.

Ideal paraSistemas de alta concorrência com modelos de leitura e escrita com requisitos de escala muito diferentes, ou onde auditabilidade completa é requisito regulatório
03

API Gateway com Backend for Frontend (BFF)

O API Gateway centraliza autenticação, rate limiting, roteamento e observabilidade para todas as APIs de backend, enquanto o padrão BFF cria APIs especializadas para cada tipo de cliente (web, mobile, parceiro) que agregam chamadas a múltiplos microserviços em um único contrato otimizado. Elimina o problema de "over-fetching" e "under-fetching" que ocorre quando clientes diferentes compartilham a mesma API genérica.

Ideal paraSistemas com múltiplos tipos de cliente (web, mobile, B2B) consumindo microsserviços distintos com necessidades de dados diferentes
04

Saga Pattern para Transações Distribuídas

Implementa transações de longa duração que atravessam múltiplos serviços como uma sequência de transações locais coordenadas por mensagens, com transações compensatórias para rollback em caso de falha. Resolve a impossibilidade de transações ACID distribuídas em microsserviços sem criar acoplamento síncrono via 2PC (two-phase commit).

Ideal paraFluxos de negócio que envolvem múltiplos serviços com estado próprio — checkout de e-commerce, onboarding de usuário, cancelamento de pedido — onde consistência eventual é aceitável
// como escolher

Escolher uma ou combinar?

A escolha de linguagem e arquitetura backend deve considerar o time existente, os requisitos de performance e o ciclo de vida esperado do sistema — não apenas rankings de popularidade. Trocar de linguagem é custoso; trocar de arquitetura é mais custoso ainda: ambas as decisões devem ser tomadas com clareza sobre os problemas que estão sendo resolvidos.

Se o time tem expertise em Python e o backend serve modelos de ML ou processa dados

use FastAPI para APIs assíncronas de alto throughput com documentação OpenAPI automática — o ecossistema Python de ML e dados integra naturalmente

Se performance de I/O e tempo de resposta são críticos com alta concorrência

considere Go ou Node.js — ambos oferecem concorrência eficiente com menor footprint de memória do que threads Java tradicionais

Se a organização tem forte presença Microsoft (Azure, .NET legado)

adote .NET com C# e ASP.NET Core — a integração com Azure AD, Entity Framework e Azure Service Bus reduz fricção de desenvolvimento e operação

Se o sistema vai crescer para múltiplos domínios de negócio com times independentes

aplique DDD para delimitar bounded contexts antes de decompor em microsserviços — decomposição prematura sem fronteiras de domínio claras cria microsserviços que precisam de transações distribuídas para tudo

Se há requisitos de processamento em tempo real com baixíssima latência

avalie Rust ou Go — a ausência de garbage collector elimina pausas imprevisíveis que afetam latência de cauda em SLAs de p99 rigorosos

Se o time está começando e a prioridade é velocidade de entrega de features

comece com um monolito bem estruturado em Python ou Node.js — microservices prematuros adicionam complexidade operacional sem benefício até que os limites de escala do monolito sejam atingidos

Diferentes linguagens backend coexistem em sistemas maduros via APIs bem documentadas — Python para serviços de ML, Go para serviços de alta performance, Node.js para BFFs e .NET para sistemas legados migrados gradualmente. Essa poliglotia é aceitável desde que cada serviço tenha contratos de API claros (OpenAPI, Protobuf, AsyncAPI) e os padrões de observabilidade — traces distribuídos, métricas, logs estruturados — sejam consistentes independentemente da linguagem. A complexidade operacional de múltiplas linguagens deve ser justificada pelo ganho técnico, não pela preferência individual de cada time.

// como a Lumi atua

Construímos backends que novos engenheiros conseguem entender em sua primeira semana — não como exercício de simplicidade forçada, mas porque código legível e bem delimitado é código que equipes conseguem evoluir sem medo. Nossa abordagem parte de modelagem de domínio antes da escolha de tecnologia, porque a arquitetura certa para o problema é sempre mais importante do que a linguagem mais popular do momento.

Princípios que aplicamos

  • Modelar bounded contexts explícitos com linguagem ubíqua documentada antes de escrever qualquer código, evitando a mistura de terminologias que confunde domínios
  • Implementar testes de unidade e integração com cobertura mínima de 80% em lógica de domínio antes de qualquer deploy em produção
  • Versionar APIs publicamente com semver e manter compatibilidade retroativa por pelo menos uma versão antes de deprecar contratos
  • Estruturar logs como JSON estruturado com correlation ID desde o primeiro request, habilitando rastreamento distribuído sem retrofit futuro
  • Revisar decisões arquiteturais com Architecture Decision Records (ADRs) versionados em Git, tornando o histórico de por quê decisões foram tomadas acessível ao time futuro

Armadilhas que evitamos

  • Decompor em microsserviços um monolito cujos domínios ainda não estão claros, criando serviços chatty que fazem centenas de chamadas síncronas entre si para completar uma única operação de negócio
  • Expor o modelo de banco de dados diretamente como API REST, criando acoplamento forte entre schema interno e contrato externo que impossibilita evolução sem breaking changes
  • Ignorar idempotência em APIs que alteram estado, causando duplicações de pedidos, cobranças ou cadastros quando clientes repetem requests com falha de rede
  • Usar exceções para controle de fluxo de negócio em vez de tipos de retorno explícitos, gerando código backend com comportamento imprevisível em cenários de erro esperados
// fundamentos

Referências acadêmicas e da indústria

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.

Introduz bounded contexts, aggregates, repositories e domain events como ferramentas para modelar software complexo alinhado ao domínio de negócio.

Fowler, M., & Lewis, J. (2014). Microservices: A Definition of This New Architectural Term. martinfowler.com.

Artigo seminal que formalizou o termo e as características de microsserviços — organização por capacidade de negócio, endpoints inteligentes, governança descentralizada.

Newman, S. (2019). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O'Reilly Media.

Guia prático de decomposição de serviços, comunicação entre microsserviços e estratégias de migração incremental de monolitos para arquiteturas distribuídas.

Martin, R. C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall.

Formaliza a regra de dependência e as camadas da Clean Architecture, garantindo que lógica de negócio seja independente de frameworks e infraestrutura.

Richardson, C. (2018). Microservices Patterns: With Examples in Java. Manning Publications.

Cataloga padrões práticos de microsserviços incluindo Saga, CQRS, API Gateway e Circuit Breaker com exemplos de implementação e análise de tradeoffs.

Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media.

Essencial para backends que gerenciam dados: cobre replicação, transações distribuídas, streams e consistência como fundamentos de sistemas confiáveis.

// próximo passo

Backends que escalam com o seu negócio

Revisamos sua arquitetura atual, identificamos gargalos de escalabilidade e dívida técnica, e desenhamos o roadmap de evolução que mantém velocidade de entrega enquanto aumenta a confiabilidade do sistema.

Avaliar meu stack →Ver todas as stacks