O que a logística elétrica em escala ensina sobre arquitetura de sistemas

A reportagem do E-Commerce Brasil sobre a To Do Green no Fórum E-Commerce Brasil 2026 é, na origem, uma matéria de negócio: transportadora fundada em 2021 em Sorocaba, mais de 500 veículos elétricos, 38 milhões de entregas e cobertura em mais de 196 cidades. Mas há uma frase da própria empresa que interessa a quem escreve software: o diferencial estaria na engenharia da operação, por ter sido "planejada desde a fundação em torno da eletrificação" em vez de ser uma "adaptação posterior de um modelo tradicional".

Esse é, na prática, o velho debate entre nascer com a restrição no centro do desenho ou tentar retrofit depois. E aqui vale traduzir o caso de logística para decisões de backend que sustentam operações de e-commerce nacionais.

First, middle e last mile viram domínios distintos

A fonte descreve uma operação end-to-end cobrindo first, middle e last mile. Do ponto de vista de sistema, esses três estágios têm requisitos bem diferentes e é tentador (e arriscado) tratá-los como um CRUD único de "pedido".

• First mile (coleta): integração com WMS e ERPs de sellers, janelas de coleta, conciliação de volumes.
• Middle mile (transferência entre hubs): planejamento em lote, previsibilidade, otimização de carga.
• Last mile (entrega final): alta cardinalidade, eventos em tempo quase real, roteirização dinâmica.

Modelar isso como bounded contexts separados costuma pagar mais do que um monólito de domínio único. Não porque monolito seja ruim (um monolito modular resolve muita operação nacional sem drama), mas porque as taxas de mudança e os SLAs de cada estágio divergem. O last mile muda de comportamento a cada campanha; o middle mile é mais estável. Acoplar os dois no mesmo modelo te obriga a fazer deploy do estável junto com o volátil.

A restrição elétrica como analogia de design

O ponto interessante do case é a restrição física: veículo elétrico tem autonomia e janela de recarga. Quando isso entra no roteirizador desde o começo, a otimização de rota deixa de ser só "menor distância" e vira um problema com estado de bateria, pontos de recarga e capacidade.

Em backend, o paralelo é direto: restrições que você conhece cedo devem virar invariantes do domínio, não filtros aplicados no fim. Quem tenta encaixar autonomia de bateria num otimizador de rota genérico depois vive o mesmo que quem adiciona multi-tenancy ou LGPD num sistema que não previu isolamento de dados: dá para fazer, mas o custo de reconversão é o que a To Do Green diz justamente ter evitado na frota.

Otimização de rotas: onde não exagerar

Roteirização é um problema clássico (variações de VRP, vehicle routing problem, notoriamente NP-difícil). A armadilha de engenharia é achar que precisa do solver ótimo desde o dia um.

Trade-offs a considerar:

• Heurística simples primeiro. Para dezenas de paradas por rota, heurísticas gulosas ou nearest neighbor com refino local resolvem bem e são fáceis de operar e testar.
• Solver dedicado depois. Bibliotecas como OR-Tools entram quando volume e restrições (janelas de tempo, capacidade, recarga) justificam. O ganho de rota economizado precisa pagar a complexidade operacional que você adiciona.
• Quando NÃO otimizar em tempo real: se as rotas são planejadas na véspera, processar em batch noturno é mais barato, previsível e depurável do que um serviço online sob pressão de latência.

Dados de CO₂: telemetria é contrato, não relatório

A matéria destaca que o CO₂ evitado é "apurado e documentado mensalmente" e usado por clientes em relatórios de ESG. Isso muda o status desse dado: ele deixa de ser métrica interna e vira saída auditável para terceiros (incluindo parceiros como Amazon e Maersk, citados na fonte).

Na prática, exige tratar telemetria de entrega como fonte imutável: eventos append-only, rastreabilidade de origem, capacidade de reprocessar um mês sem alterar o histórico. Um data warehouse alimentado por eventos de domínio serve melhor aqui do que agregações calculadas na mão em cima do banco transacional, que você não consegue reauditar depois.

O que fica

O case não traz detalhes técnicos da stack, então qualquer afirmação sobre a arquitetura real da To Do Green seria invenção. O que ele oferece é um lembrete concreto: restrição conhecida cedo é barata; restrição empurrada para o retrofit é o custo que corrói margem. Vale para frota elétrica e vale igualzinho para o sistema que despacha os pedidos.

Fonte: E-Commerce Brasil