gmulato / backend · arquitetura

Software Engineer

Guilherme
Mulato

Backend· Architecture· SaaS· distributed systems

Desenvolvedor full-stack com foco em backend, arquitetura de software e construção de sistemas SaaS complexos.

Tenho experiência projetando e operando sistemas distribuídos, integrações de alto volume, processamento assíncrono, modelagem avançada em PostgreSQL, realtime, infraestrutura e aplicações multi-tenant.

Atuo desde a definição do problema e da arquitetura até implementação, deploy, observabilidade e evolução do produto em produção.

01 / Sobre

exp
~3 anos
papel
Tech Lead / Backend
time
3 devs
core
PHP · Laravel · PostgreSQL · Redis

Desenvolvo software profissionalmente há quase 3 anos e atualmente curso o último semestre de Tecnologia em Sistemas para Internet no IFSP.

Minha principal especialidade é backend e arquitetura, especialmente com PHP, Laravel, PostgreSQL, Redis e infraestrutura baseada em containers.

Ao longo da minha experiência, trabalhei tanto em produtos internos críticos para operação de empresas quanto em projetos de software house nos setores imobiliário, food service e sistemas corporativos.

Também já atuei como Tech Lead, liderando tecnicamente uma equipe de três desenvolvedores e participando diretamente das principais decisões de arquitetura, infraestrutura e produto.

Sistema interno responsável por grande parte da operação de uma empresa de arbitragem de tráfego digital.

A plataforma integrava Meta Ads, Google Ad Manager e diferentes intermediadores de Ad Exchange, centralizando criação e acompanhamento de campanhas, tracking, receita, contingência de contas, pagamentos, comissões, alertas e automações operacionais.

Timeline do produto

V1 · MVP solo

Comecei desenvolvendo sozinho o primeiro MVP, que entrou em produção em aproximadamente três meses e permaneceu sendo utilizado por cerca de um ano e meio.

V2 · liderança técnica

Posteriormente, liderei a arquitetura e o desenvolvimento da segunda geração da plataforma, incluindo toda a base de sincronização de dados.

Pipeline de sincronização

A arquitetura utilizava processamento assíncrono dividido em diferentes etapas:

source Meta Ads
GAM
AdX
01 coleta rate limit
retries · backoff
02 staging
append-only
03 filas de
ingestão
workers stateless
idempotência
04 modelo
temporal
ranges · GiST
out dashboards
automações
alertas
reprocessamentoreconciliaçãolocks distribuídostolerância a falhas

O desenho permitia reprocessamento, reconciliação de dados não ingeridos, tolerância a falhas e isolamento entre coleta e atualização do domínio.

Foram utilizados:

  • workers stateless;
  • filas separadas por responsabilidade;
  • controle de rate limit;
  • retries e backoff;
  • locks distribuídos;
  • middleware de idempotência;
  • timestamps da origem para evitar processamento de dados antigos sobre estados mais recentes;
  • reconciliação automática de dados.
O problema temporal

A operação possuía aproximadamente 800 contas de anúncio, centenas de campanhas e sincronizações recorrentes em intervalos curtos.

Como gasto e receita vinham de sistemas diferentes e a receita do Google Ad Manager podia chegar com horas de atraso, era necessário reconstruir corretamente o estado da operação em diferentes momentos do tempo.

campanha A
ACTIVE
PAUSED
ACTIVE · budget+
campanha B
DRAFT
ACTIVE
receita GAM
janela t-4 … t-2
a receita chega horas depois de now e reescreve o passado — a janela t-4 … t-2 é recalculada.
t-4t-3t-2t-1now
estado vigente estado anterior dado atrasado

Foi desenvolvido um modelo temporal utilizando PostgreSQL, ranges e índices GiST para representar alterações de estado ao longo do tempo.

Além disso, como algumas métricas externas eram fornecidas apenas como valores acumulados, foi criado um histórico baseado em deltas entre sincronizações.

Isso permitia identificar, inclusive dias depois, correções positivas ou negativas feitas pelas próprias plataformas.

valor acumulado (origem)

delta entre sincronizações

delta negativo = correção da plataforma

Infraestrutura

Também fui responsável pela infraestrutura da operação, incluindo aproximadamente 20 sites WordPress com tráfego internacional, Cloudflare, Linux, Docker, CI/CD e deploys.

Em períodos de maior volume, o ecossistema recebia milhões de acessos diariamente.

{{ t }}

03 / Outros sistemas

02

Engine de distribuição de tráfego

Sistema de alta performance responsável pela distribuição de tráfego entre diferentes destinos.

O projeto funcionava como uma engine simples de split testing, permitindo dividir acessos entre destinos utilizando percentuais configuráveis.

O Redis era utilizado no caminho crítico da requisição para reduzir o custo de decisão e manter o redirecionamento extremamente rápido.

O sistema acabou servindo como uma das primeiras experiências que posteriormente influenciaram ideias mais amplas de roteamento e orquestração de tráfego.

{{ t }}

03

Plataforma de delivery e gestão para restaurantes

Participação no desenvolvimento de um ecossistema de food service envolvendo marketplace de delivery, cardápios web e gestão operacional de estabelecimentos.

Um dos principais desafios técnicos está na modelagem de entrega e descoberta geográfica.

O sistema permite configurar regras de entrega utilizando zonas geográficas complexas, incluindo áreas multipoligonais, limites de distância e diferentes condições comerciais.

PostGIS é utilizado para consultas espaciais, validação de cobertura e processamento geográfico.

Também trabalhei em problemas relacionados a:

  • {{ i }}
{{ t }}

04

Plataforma imobiliária

Desenvolvimento de sistema corporativo para operação imobiliária.

A plataforma centraliza diferentes partes do negócio, incluindo:

  • {{ i }}

Também foi desenvolvido um sistema personalizado de organização e gerenciamento de arquivos inspirado em plataformas como Google Drive, porém adaptado aos processos internos da empresa.

O projeto envolve modelagem de domínio, integrações externas, controle de acesso e automação de processos empresariais.

04 / Experiência técnica

{{ g.name }} {{ g.count }}

  • {{ i }}

Também possuo experiência profissional com outras tecnologias, incluindo Flutter, Vue e Ruby.

— / Como penso software

Minha principal preocupação não é apenas fazer uma funcionalidade funcionar, mas entender como ela continuará funcionando quando existirem concorrência, falhas externas, dados atrasados, crescimento de volume e novas regras de negócio.

Gosto especialmente de problemas onde arquitetura, modelagem de dados e produto precisam ser pensados em conjunto.

Sistemas distribuídos, processamento assíncrono, modelagem temporal, multi-tenancy e integrações complexas são algumas das áreas nas quais mais gosto de trabalhar.

05 / Contato

Tecnologia em Sistemas para Internet — IFSP

Conclusão prevista para 2026.

GitHubadicionar link LinkedInadicionar link E-mailadicionar e-mail