// stack.lumi

Backend

Go

Backend performatico, simples e confiavel.

// o que é

Go e uma linguagem compilada criada para servicos concorrentes, CLIs e infraestrutura. No contexto da Lumi Data, Go e forte quando performance, simplicidade operacional e binarios leves importam.

Go foi projetado no Google em 2007 com o objetivo explícito de resolver os problemas de engenharia de software em escala: compilação lenta, dependências implícitas, dificuldade de leitura de código alheio e falta de suporte à concorrência moderna — conforme documentado por Pike (2012) na SPLASH. O modelo de concorrência de Go é baseado em CSP (Communicating Sequential Processes), formalizado por Hoare (1978) nas Communications of the ACM: em vez de memória compartilhada com locks, goroutines se comunicam via channels, eliminando classes inteiras de condições de corrida e deadlocks. Goroutines são multiplexadas em threads do SO pelo runtime do Go, permitindo que dezenas de milhares de goroutines coexistam com overhead de memória na ordem de kilobytes por goroutine — em contraste com stacks de threads do SO que consomem megabytes. O compilador Go produz binários estáticos sem dependências externas, simplificando radicalmente o deploy em containers e ambientes de produção onde ausência de runtime instalado é um requisito operacional.

Como a Lumi enxerga:A Lumi usa Go para componentes criticos, sempre conectado a observabilidade, testes e contratos claros com outros sistemas.

// na prática

Como empresas usam Go

Empresas de infraestrutura e plataformas cloud-native (Google, Docker, Kubernetes, Cloudflare)

Adotam Go como linguagem primária para ferramentas de infraestrutura, proxies reversos, orquestradores e agentes de monitoramento. A combinação de binários estáticos, baixo consumo de memória e concorrência eficiente com goroutines torna Go ideal para componentes que precisam escalar horizontalmente sem overhead de JVM ou interpretador.

Fintechs e empresas de pagamento com APIs de alto throughput

Utilizam Go para microsserviços de processamento de transações, gateways de pagamento e serviços de autenticação onde a latência de cauda (p99) é um SLA de negócio. O garbage collector de baixa pausa do Go — com pausas tipicamente abaixo de 1ms em versões recentes — é mais previsível do que o de linguagens JVM para serviços que exigem latência consistente.

Times de plataforma e SRE em empresas de tecnologia (Mercado Livre, PicPay, Conta Azul)

Constroem ferramentas internas de CLI, daemons de monitoramento, proxies de integração e serviços de infraestrutura em Go, aproveitando a distribuição de binários únicos sem necessidade de gerenciar ambientes de runtime em cada servidor ou container de destino.

// decisão técnica

Quando usar — e quando não usar

Use quando

O serviço tem requisitos de latência de cauda (p99) abaixo de 10ms com concorrência alta — goroutines e o GC de baixa pausa de Go entregam previsibilidade que Python e Node.js não garantem
O componente é infraestrutura de plataforma (CLI, daemon, proxy, agent) onde binário estático sem dependências de runtime simplifica deploy e distribuição
O serviço precisa lidar com dezenas de milhares de conexões simultâneas (websockets, gRPC streams, event processing) — o modelo CSP de Go é idiomático e eficiente para este padrão
O time precisa de uma linguagem com curva de aprendizado baixa para novos membros, sintaxe deliberadamente simples e toolchain unificada (gofmt, go test, go build)
O microsserviço tem responsabilidade bem delimitada, interface estável e precisa de desempenho máximo com footprint de memória mínimo em produção

Evite quando

O projeto é um CRUD simples com lógica de negócio moderada e o time já opera Python ou Node.js — a rigidez de Go (ausência de generics histórica, verbosidade de error handling) adiciona fricção sem ganho de performance perceptível neste contexto
O domínio requer ecossistema de data science ou ML — Go carece de bibliotecas maduras para pandas, scikit-learn ou PyTorch, e a fronteira de serialização com Python anularia os ganhos de performance
O time é 100% Python e não existe justificativa de performance medida para introduzir Go — diversidade de linguagem tem custo real de manutenção, onboarding e contratação que precisa ser pago com dados, não com intuição
O sistema é um monólito de domínio complexo onde a expressividade de Java com DDD (Evans, 2003) ou a produtividade de Python seriam mais adequadas para modelar regras de negócio ricas

// visão lumi

A Lumi escolhe Go quando existe justificativa técnica medida, não quando Go soa impressionante no contexto do projeto. Para microsserviços de infraestrutura, proxies de dados e componentes de processamento paralelo com requisitos de latência documentados, Go é a escolha mais honesta. Em projetos de dados ou IA, Python permanece como padrão mesmo que Go seja "mais rápido" — a diferença de performance raramente justifica o custo de operar duas linguagens. Quando Go entra no stack, exigimos interfaces explícitas, testes com go test cobrindo casos de borda de concorrência e erros tratados explicitamente — o famoso "if err != nil" é uma feature de design, não ruído sintático.

Lumi escolhe quando

Quando o serviço tem requisito de latência de cauda documentado e benchmarks demonstram que Python ou Node.js não atingem o SLA com a infraestrutura disponível
Quando o componente é um daemon de infraestrutura, CLI ou agente que será distribuído como binário único — Go elimina a necessidade de gerenciar runtimes em ambientes heterogêneos
Quando o sistema de microsserviços tem um subconjunto de serviços com concorrência massiva (streams, websockets, event processing) que se beneficiam do modelo CSP de goroutines e channels
Quando o time tem pelo menos um engineer com fluência real em Go e os demais têm disposição documentada de aprender — Go sem domínio do modelo de memória e concorrência gera bugs sutis difíceis de reproduzir

Lumi não recomenda quando

Go em projetos onde Python já resolve o problema com maturidade de ecossistema e sem gargalo de performance medido — trocar linguagem sem evidência de problema é résumé-driven development clássico
Go como primeira linguagem de um time novo sem nenhum membro com experiência em sistemas concorrentes — o modelo de goroutines e channels parece simples mas produz data races sutis em times sem cultura de testing de concorrência

// aplicações

Onde essa tecnologia gera valor

Microservicos

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Processamento concorrente

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Servicos de infraestrutura

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

APIs de alta performance

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

// fundamentos

Referências acadêmicas e técnicas

Pike, R. (2012). Go at Google: Language Design in the Service of Software Engineering. SPLASH 2012, Proceedings of the 3rd Annual Conference on Systems, Programming, and Applications.

Documentação autoritativa das motivações de design do Go por um de seus criadores: compilação rápida, concorrência como cidadã de primeira classe e legibilidade como requisito de engenharia em escala.

Hoare, C.A.R. (1978). Communicating Sequential Processes. Communications of the ACM, 21(8), 666–677.

Fundamento teórico do modelo de concorrência do Go: CSP define a comunicação via canais como primitiva de sincronização, base intelectual das goroutines e channels.

Donovan, A.A.A. & Kernighan, B.W. (2015). The Go Programming Language. Addison-Wesley Professional.

Referência técnica canônica da linguagem, cobrindo o modelo de tipos, interfaces implícitas, goroutines, channels e práticas de produção recomendadas pelos autores da linguagem.

Google (2024). The Go Programming Language Specification. go.dev/ref/spec.

Especificação formal da linguagem, incluindo semântica de memória, modelo de goroutines e garantias do runtime que fundamentam decisões de arquitetura em sistemas concorrentes.

Newman, S. (2019). Building Microservices, 2nd ed. O'Reilly Media.

Discute tradeoffs de microsserviços e os contextos onde linguagens como Go são escolhas naturais para serviços independentes com requisitos de performance e footprint controlado.

// tecnologias relacionadas

Backend

// próximo passo

Quer saber se esse stack faz sentido para você?

A Lumi avalia contexto, dados, equipe, custo e maturidade para recomendar a tecnologia certa e entregar com responsabilidade.

Avaliar meu stack →Voltar ao stack