Status de Conexão dos Parceiros no iFood

Esse artigo tenta explicar o porque recomendamos realizar o polling de eventos de 30 em 30 segundos.

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 estar conectado no tópico do merchant do nosso broker MQTT (ainda não disponível para integrações no momento).

Toda* request de polling envia um heartbeat que é processado assincronamente por nossos serviços internos. Ao fazer um polling garantimos que o merchant fique imediatamente online na plataforma (ou continue online). A questão que surge é: quando podemos assumir que o merchant ficou offline a partir do último heartbeat?

Poderíamos simplesmente dizer que após um tempo X que todo e qualquer merchant está offline. O problema é que temos parceiros com conexões à internet de baixa qualidade, e escolher um tempo X muito baixo faz com que o status deles oscilem muito na plataforma, o que reduz, e muito, a possibilidade de eles receberem pedidos. Por outro lado, escolher um X muito alto significa um aumento no número de pedidos cancelados sem confirmação, onde o parceiro fecha o app mas continua online na plataforma por um período de tempo maior do que o desejado.

Por conta disso temos dois valores que ditam o tempo para dizer se um merchant está offline: uma constante de 45 segundos (valor configurado atualmente) para todos os merchants e um tempo extra calculado individualmente para cada merchant levando em consideração o tempo em que ele fica sem enviar heartbeats (sem fazer polling com sucesso), que chamamos de tempo de flapping. Esse tempo também pode chegar a 45 segundos, totalizando um tempo máximo de 90 segundos até o merchant ficar offline na plataforma.

É por conta disso que recomendamos o polling de 30 em 30 segundos, onde um polling pode falhar mas ainda sim o merchant continuará online na plataforma até o próximo polling, com um pouco de tempo de sobra. Caso o intervalo seja superior a esse tempo, corre o risco do merchant ser fechado na plataforma, e por isso é importante garantir a regularidade do polling!

* Apenas requests de polling com um header específico não emitem heartbeats. Esse header é utilizado em cenários em que o cliente consome eventos sem alterar o status do merchant para online (modo oculto), mas isso é assunto para um outro artigo.