* CASE STUDY Nº 01 · BAMSE / UNILEVER · 2025

OMO Lavanderias

Um ecossistema cross-platform para mais de um milhão de usuários da maior marca de cuidado de roupas do Brasil — pedidos, reservas, pagamentos e notificações em microsserviços que precisam funcionar todo dia.

1M+ USUÁRIOS ATIVOS
4 PLATAFORMAS
7+ MICROSSERVIÇOS
24/7 OPERAÇÃO CONTÍNUA
i O PROBLEMA

Cuidar de roupa precisa ser tão simples quanto pedir comida.

Atender mais de um milhão de usuários da Unilever em todo o Brasil é um problema operacional sério. Pedidos precisam casar com lavanderias parceiras, reservas têm que respeitar capacidade e horário, pagamentos não podem falhar e notificações precisam chegar no momento certo — em iOS, Android, Web e nos apps internos das lojas.

O ecossistema cresceu organicamente. Quando entrei, havia oportunidades reais de simplificação, idempotência e controle de concorrência — especialmente nas fronteiras entre serviços.

ii MEU PAPEL

Engenheiro Pleno full-stack, focado em backend e nos contratos entre serviços.

  • — Manutenção e evolução de microsserviços de pedidos, reservas, pagamentos e notificações.
  • — Controle de concorrência com Redis/Redlock; webhooks idempotentes; coreografias SAGA entre serviços.
  • — Code reviews, definição de padrões de engenharia e mentoria para o time.
  • — Participação no Comitê de IA da Bamse — pesquisa aplicada de agentes para acelerar partes do próprio fluxo de engenharia desse projeto.
iii STACK & ARQUITETURA
BACKEND
NestJSTypeScriptFastifyREST / OpenAPI
CLIENTES
React NativeExpoReact (Web)Electron
DADOS, INFRA & PADRÕES
PostgreSQLRedis / RedlockRabbitMQSAGADDDDocker
iv PROCESSO
01

Mergulho no domínio antes de qualquer linha de código.

Conversas com produto, operação e atendimento da OMO para entender o vocabulário, os SLAs reais e onde os atritos doem mais.

02

Mapeamento de contratos e pontos críticos de concorrência.

Definir o que precisa de idempotência (webhooks de pagamento), o que precisa de Redlock (reserva de slot) e o que pode ser eventual.

03

Implementação em fatias verticais e observáveis.

Cada fatia entrega valor e fica visível em logs/métricas — assim conseguimos validar com operação real antes de seguir.

04

Code review, padronização e mentoria como contrato do time.

O time fica mais rápido quando o padrão está escrito — e quando a revisão é técnica e generosa ao mesmo tempo.

v RESULTADOS

Sistema mantém-se estável atendendo 1M+ usuários, com fluxos críticos de pedido, reserva e pagamento confiáveis o suficiente para não acordar o time no meio da noite.

  • — Webhooks de pagamento idempotentes eliminaram retrabalho manual de operação em casos de reentrega.
  • — Redlock em reservas de slot eliminou a condição de corrida que gerava double-booking em horários de pico.
  • — Padrões de revisão e ADRs adotados pelo time reduziram a variabilidade entre PRs e o tempo de onboarding de novos devs.
  • — Aprendizados do Comitê de IA aplicados ao próprio fluxo: skills e hooks específicos do projeto aceleraram refactors recorrentes.
VISUAL · PLACEHOLDER
app mobile — fluxo de pedido
painel da loja — gestão de slots
PRÓXIMO CASE STUDY

Distribuição de Energia — Fox IoT