Sem amarras: a filosofia por trás das nossas arquiteturas modulares

Em vez de depender de um único fornecedor, construímos sistemas com peças independentes que podem ser trocadas sem quebrar o todo. Conheça as camadas da nossa arquitetura.

Resumo — Em vez de depender de um único fornecedor, construímos sistemas com peças independentes que podem ser trocadas sem quebrar o todo. Este artigo mostra as camadas da nossa arquitetura e por que essa abordagem dá mais controle e previsibilidade de custos para o cliente.

Quando uma empresa decide construir uma solução digital proprietária, a tendência do mercado é empurrá-la para dentro do ecossistema fechado de uma única grande corporação. Seja assinando todas as caixas da Microsoft, da AWS ou do Google, a promessa é sempre a mesma: a conveniência de ter tudo sob o mesmo teto.

No entanto, o campo de batalha do desenvolvimento nos ensinou que essa conveniência cobra um preço alto a longo prazo. Ficar refém de um único fornecedor (*vendor lock-in*) significa aceitar que uma mudança unilateral na tabela de preços deles ou uma alteração de política de dados pode quebrar a viabilidade financeira do seu negócio do dia para a noite.

Para garantir previsibilidade de custos, segurança e desempenho, nós desenhamos nossos sistemas sob uma filosofia diferente: a arquitetura modular descentralizada. Em vez de usar as ferramentas de uma única empresa, nós escolhemos a dedo as melhores tecnologias do mercado para cada função específica.

Abaixo, abrimos os bastidores da engenharia relacional que serve de espinha dorsal para as nossas aplicações.

O ecossistema descentralizado: cada um no seu papel

Para que o sistema aguente picos de milhões de acessos (como no dia de uma matrícula ou de um grande exame) sem que o custo de TI saia do controle, dividimos a estrutura em camadas independentes que trabalham em harmonia:

1. Nuxt hospedado na Cloudflare (a ponta)

A interface que o usuário acessa é construída em Nuxt e distribuída de forma global através da rede de borda (Edge) da Cloudflare. Na prática, as páginas do sistema são servidas a partir de servidores fisicamente próximos de onde o usuário está acessando, reduzindo a latência e aliviando a carga de qualquer servidor central.

2. PostgreSQL via Supabase (o coração relacional)

Para o banco de dados e a autenticação, utilizamos o PostgreSQL gerenciado pelo Supabase. A escolha do Supabase como plataforma foi estratégica: ele nos entrega toda a potência do Postgres com uma camada de segurança e uma API pronta, acelerando o desenvolvimento.

A grande vantagem, no entanto, é a portabilidade. O banco de dados continua sendo Postgres puro. Diferente de outros fornecedores de banco de dados como serviço que usam tecnologias proprietárias e te prendem ao ecossistema deles, o Supabase permite que a qualquer momento você extraia todo o banco e migre para sua própria infraestrutura ou para outro provedor compatível com Postgres. Se o custo ou o serviço deixar de valer a pena, temos um plano de saída claro e executável — sem precisar reescrever uma linha de código.

3. Workers vs. Edge Functions (a divisão de carga)

Não sobrecarregamos a aplicação misturando as regras de comunicação:

  • Cloudflare Workers: Cuidam das lógicas leves e rápidas que interagem diretamente com a página do usuário.
  • Supabase Edge Functions: Tratam da lógica pesada e das operações complexas de escrita e leitura que conversam diretamente com o banco de dados.

4. Digital Ocean (a âncora para trabalho bruto)

A infraestrutura sem servidor (serverless) é fantástica para páginas e bancos de dados, mas existem tecnologias que exigem servidores robustos e de processamento contínuo. É aqui que entra a Digital Ocean. Usamos essa infraestrutura para hospedar aplicações que demandam computação pesada em Python, como os módulos de processamento de dados e reconhecimento facial em portaria de escolas.

💡 A analogia da oficina vs. a concessionária exclusiva

Para entender a diferença de eficiência dessa abordagem, imagine a manutenção de uma frota de veículos:

A abordagem do fornecedor único é como comprar carros de uma marca que só aceita peças originais da própria fábrica e exige que toda manutenção seja feita na concessionária deles. No início parece simples, mas no primeiro problema fora da garantia, você descobre que o preço da peça triplicou e você não tem alternativa a não ser pagar o que eles pedem.

A nossa arquitetura modular funciona como uma oficina de alto desempenho: nós montamos a estrutura usando o melhor chassi do mercado (Nuxt), o motor mais confiável do mundo (Postgres) e a blindagem de segurança mais rígida disponível (Cloudflare). Se uma dessas peças precisar ser substituída ou atualizada no futuro, nós trocamos apenas aquele módulo específico. O sistema continua rodando e a empresa mantém o controle total sobre o código e os custos de TI.


Principais pontos

  • A dependência de um único fornecedor (vendor lock-in) expõe o negócio a riscos financeiros e técnicos
  • Uma arquitetura modular descentralizada permite trocar peças sem reescrever o sistema
  • O Supabase foi escolhido por entregar Postgres puro com portabilidade real — diferente de outros provedores
  • Cloudflare Workers e Supabase Edge Functions dividem as responsabilidades de forma eficiente
  • A Digital Ocean entra onde o serverless não é suficiente: processamento pesado e contínuo

O próximo passo: controle sem amarras

Construir softwares independentes dá mais trabalho na fase de planejamento? Sim. Mas o resultado é uma plataforma escalável, segura e que respeita a saúde financeira do cliente.

Se a sua empresa quer sair das amarras dos grandes ecossistemas e construir uma arquitetura que realmente te pertence — clique aqui para bater um papo conosco e descobrir como podemos ajudar.