Presença

Essa página se propõe a explicar um pouco do conceito de presença no iFood e como presença está relacionada com a entrega de eventos no iFood.

Contexto

Quem nunca fez um pedido, deixou o celular de lado e só voltou a checar meia hora depois para ver que o pedido havia sido cancelado por falta de confirmação do pedido? Não é somente uma experiência extremamente ruim para o usuário como também pode acarretar em penalizações ao parceiro por ter cancelamentos sem justificativa.

No iFood estamos sempre trabalhando para melhorar a experiência dos nossos clientes, e por isso tentamos identificar se o merchant realmente está apto a receber pedidos naquele momento de maneira a reduzir essa má experiência.

Para um merchant aparecer como aberto no aplicativo, vários critérios precisam ser atendidos, como: estar dentro do horário de funcionamento configurado, ter um cardápio configurado e algumas outras condições. Um critério extremamente importante é “estar online na plataforma”.

Hoje nós definimos um merchant como “online na plataforma” se ele estiver recebendo eventos de pedidos. Na prática, hoje isso significa que o merchant deve:

• Ou estar fazendo polling de eventos com uma conta com acesso àquele merchant;
• Ou ter um servidor para webhooks recebendo eventos de forma saudável;
• Ou estar conectado no tópico do merchant do nosso broker MQTT (ainda não disponível para integrações no momento).

Essa capacidade de identificar se há alguém processando eventos é o que chamamos de presença. Algo equivalente ao status "online" em uma conversa do WhatsApp.

Heartbeat (ou keepalive)

Fazemos uso de heartbeats para os meios de entrega que não fazem uso de uma conexão persistente (hoje: polling e webhook).

Heartbeats nada mais são do que mensagens periódicas que indicam que há alguém escutando os eventos de um merchant.

No caso do polling, nossos serviços geram eventos de heartbeat a cada request de polling de acordo com os merchants com scope order disponíveis no token, ou passados no header x-polling-merchants quando utilizado.

No webhook o controle é inverso, onde enviamos requests periódicas para o servidor registrado no webhook para analisar o status do servidor, com controle fino por merchant para as integrações que tiverem esse controle no lado delas. Para saber mais: