Na Robbin, desde o início, optamos por um caminho alternativo ao debate clássico entre monólitos e microsserviços. Adotamos o modelo de micro-monólitos, que combina o melhor dos dois mundos: a coesão e simplicidade dos monólitos com a independência e escalabilidade dos microsserviços. Neste artigo, explicamos como estruturamos nossa engenharia, como organizamos os times e quais práticas garantem que esse modelo funcione de verdade no dia a dia.
Organização por times e micro-monólitos
Nossa engenharia é dividida em times, e cada time é responsável por um ou mais micro-monólitos. Na prática, isso significa que cada sistema é:
- Coeso: agrupa domínios de negócio relacionados, evitando fragmentação excessiva.
- Modular: compartimentaliza funcionalidades em módulos internos bem definidos.
- Independente: tem seu próprio ciclo de deploy, permitindo evoluir no ritmo do time.
Exemplo de estrutura na Robbin
- Experiência: mantém os sistemas voltados à interface e relacionamento com o usuário, como BFF (Backend for Frontend), Notificações e Legal Entity (com módulos pessoa jurídica, perfil, campanhas de leads, contratos etc.).
- Crédito: Cuida dos domínios de análise de risco, limites de crédito e também dos pagamentos (cobrança, webhooks, reconciliação).
- Cards: responsável pelo sistema de cartões, incluindo emissão, bloqueio/desbloqueio e faturas.
Acoplamento forte entre time e sistema
Cada time é o “dono” de seus sistemas: tem autonomia total para definir, construir, operar e evoluir os micro-monólitos sob sua responsabilidade. Isso garante alinhamento entre os objetivos do time e as decisões técnicas, evitando gargalos típicos de times funcionais ou silos de conhecimento.
Módulos internos e interfaces claras
Os micro-monólitos concentram múltiplos módulos e responsabilidades, mas expõem apenas interfaces claras e estáveis para o resto da empresa. Assim, evitamos dependências acidentais e promovemos integrações mais simples, baseadas em contratos bem definidos (via APIs (rest ou grpc) ou filas de eventos).
Cultura open source interna
Embora cada time seja responsável pelos sistemas que mantém, adotamos uma cultura “open source” dentro da empresa: qualquer engenheiro pode propor melhorias ou correções em qualquer micro-monólito, mas a decisão final (curadoria e aprovação) é sempre do time responsável. Isso estimula a colaboração, mas preserva clareza sobre quem mantém o quê.
Boas práticas para evitar a bagunça
O modelo só funciona porque adotamos práticas rígidas de engenharia:
- Infraestrutura como código: tudo provisionado via Terraform, sem ambientes manuais.
- Deploys automatizados: pipelines CI/CD para cada micro monolito.
- Observabilidade: monitoramento e alertas centralizados no Datadog.
- Cultura de revisão de código: todo merge passa por revisão, promovendo qualidade e compartilhamento de conhecimento.
Liberdade tecnológica com responsabilidade
Os times têm autonomia para escolher as tecnologias que consideram mais adequadas — desde que seja Python ou Go. Essa liberdade, no entanto, vem com responsabilidade: seguimos padrões mínimos de engenharia, automação, observabilidade e segurança, que garantem a manutenção do ecossistema poliglota com qualidade.
Por que micro-monólitos funcionam na Robbin
O modelo reflete nossa filosofia organizacional: autonomia real para os times, alinhamento entre estrutura técnica e estrutura de pessoas, e um compromisso com engenharia pragmática. Ao acoplar times e sistemas, evitamos os problemas tanto dos monólitos gigantes quanto do excesso de microsserviços frágeis.
IA como aliada da produtividade
Este texto, assim como boa parte da nossa documentação e processos internos, foi produzido com apoio de ferramentas de inteligência artificial — já incorporadas no nosso dia a dia para ganho de eficiência, revisão e automação.
Próximo capítulo: por que poliglotas?
No próximo post, vamos contar por que começamos a Robbin com uma stack poliglota (Python, Go, Javascript e Flutter) e como essa decisão se conecta com nosso modelo organizacional.