Ce fichier explique comment un client récupère après une coupure WebSocket. Il s'adresse aux développeurs frontend et mobiles.

1. Reconnecter avec un backoff progressif (par exemple 1, 2, 4, 8 puis 30 secondes avec jitter), sans boucle agressive.
2. Après chaque reconnexion, relire GET /food/v1/orders/{order_id}, le paiement et la livraison concernés. Le WebSocket n'a pas de replay.
3. Remplacer l'état local par la réponse HTTP faisant autorité; un événement reçu n'est jamais une preuve suffisante d'un état financier.
4. Afficher un fallback quand la socket est indisponible et continuer à utiliser les routes HTTP.

La connexion est en mémoire dans un processus Food. Si plusieurs réplicas sont déployés, un fan-out Redis est PRÉVU et doit être validé avant activation multi-instance.