O quick commerce e a prateleira digital dinâmica: notas de arquitetura por trás do modelo Daki

Uma entrevista de Eduardo Galanternick, COO do Daki, publicada pelo E-Commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → Brasil, foca no discurso de negócio (conveniência, hábito de consumo, ocasiões de compra). Mas por baixo das frases sobre "liberdade para consumir" há decisões de arquitetura de dados e engenharia operacional que valem uma leitura pela ótica de quem escreve o backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) →. Vamos separar o marketing do que de fato muda no desenho de sistema.

O ponto técnico que importa: sortimento não é catálogo completo

A afirmação mais interessante da entrevista, do ponto de vista de engenharia, é esta: "Não buscamos ter o maior número possível de SKUs, mas oferecer o mix mais adequado para cada perfil de consumo." Galanternick diz que a empresa "nasceu como uma empresa de tecnologia" e usa inteligência de dados para construir sortimento por região.

Traduzindo para termos de backend: o catálogo não é uma tabela única e global. É um catálogo segmentado por dark store / região, onde a disponibilidade e o mix de produtos variam conforme sinais de demanda local. Isso muda bastante o modelo de dados. Em um e-commerce tradicional, produto e estoque tendem a ser entidades relativamente estáveis. No quick commerce, a relação (produto × loja × momento) vira a unidade de decisão, e ela é volátil.

Prateleira "dinâmica" quer dizer o quê, na prática

A entrevista descreve a prateleira como algo que "evolui conforme entendemos melhor o comportamento dos consumidores". Isso é marketing, mas o correlato técnico é concreto: a definição de sortimento passa a considerar comportamento de compra, sazonalidade, preferência regional e padrões ao longo do dia.

Esse último ponto é o que costuma pegar engenheiro de surpresa. Sortimento que muda por hora do dia (café da manhã, happy hour, ceia) implica que a ordenação e a curadoria da vitrine são resultado de um pipeline de dados, não de uma configuração manual no admin. Na prática, isso empurra o time para algo como:

• Ingestão de eventos de compra e navegação em near real time;
• Camada analítica que agrega por loja, região, faixa horária e ocasião;
• Serviço de catálogo/ranking que consome esses agregados e monta a vitrine por contexto.

O trade-off honesto: prateleira dinâmica aumenta relevância e disponibilidade, mas custa em complexidade e reprodutibilidade. Vitrine que muda sozinha é mais difícil de testar, de debugar ("por que esse SKU sumiu para esse CEP às 19h?") e de auditar. Se o negócio não tem volume nem variação real de demanda que justifique, um catálogo estático com regras simples resolve com muito menos dor operacional. Nem todo e-commerce precisa de pipeline de streaming; a maioria não precisa.

A promessa de entrega puxa a modelagem

Há uma restrição forte embutida na frase "mantém a promessa de entrega rápida". Entrega em minutos só fecha se a disponibilidade exibida for verdadeira no momento da exibição. Isso significa que consistência de estoque deixa de ser detalhe e vira requisito de primeira ordem.

Um catálogo enxuto por loja ajuda justamente aqui: menos SKUs por operação reduzem a superfície de erro de estoque e simplificam a reposição. É uma decisão de produto que também é uma decisão de arquitetura, menos itens significam menos cardinalidade para sincronizar entre estoque físico, sistema e vitrine. O executivo credita a isso ganho de "eficiência operacional", o que faz sentido: restringir o domínio é uma forma clássica de tornar um sistema mais confiável.

O que fica para quem constrói

A fonte não é um material técnico, é uma entrevista de negócio para o Fórum E-Commerce Brasil 2026. Ainda assim, vale destilar o que ela sinaliza para times de backend em logística e varejo:

1. Modele por contexto, não só por produto. Se demanda varia por região e horário, a chave de decisão do catálogo é composta, não é o SKU sozinho.
2. Trate disponibilidade como dado quente. Promessa de entrega curta transforma consistência de estoque em requisito, não em nice-to-have.
3. Comece simples. Pipeline de dados para vitrine dinâmica só se paga com escala e variação reais. Antes disso, regras estáticas versionadas são mais baratas e mais auditáveis.

O discurso de "empresa de tecnologia que vende mercado" é comum e às vezes vazio. Mas a parte defensável, sortimento enxuto por loja guiado por dados de demanda, é uma escolha de arquitetura legítima, com custos claros. A pergunta que todo time deveria fazer antes de copiar o modelo é a de sempre: o seu contexto tem volume e volatilidade que justifiquem essa complexidade? Se não tiver, o mix estático segue sendo uma resposta perfeitamente boa.

Fonte: E-Commerce Brasil