Système de livraison Redis ↔ MongoDB
Un même cycle. Deux façons de gérer les événements.
Un même workflow de livraison implémenté deux fois, pour comparer la propagation d’événements et l’accès à un état qui évolue.
Backend · Événements · Projet individuel · 2025
- Python
- Redis
- MongoDB
- Git
- Bash
L’idée de départ.
Comparer la propagation d’événements et le suivi d’un état persistant en implémentant un même cycle de commande avec Redis et MongoDB.
Ce que j’ai construit.
Ma contribution personnelle au projet.
Projet individuel. Conçu et implémenté seul.
Deux implémentations du cycle
Client, gestionnaire et livreur font progresser une commande le long d’un même cycle. Une version repose sur Redis Pub/Sub et des structures explicites. L’autre sur un document de commande MongoDB observé par Change Streams.
Deux réponses au même problème.
Le client, le gestionnaire et le livreur font progresser la même commande. Ce qui change entre les versions, c’est la façon de propager les événements et de lire l’état.
Faites défiler le tableau horizontalement pour tout lire.
| Point comparé | Redis | MongoDB |
|---|---|---|
| Mécanisme | Pub/Sub | Change Streams |
| Organisation | Structures explicites et événements publiés | Document de commande observé pendant ses mises à jour |
| Ce que cette version met en évidence | La propagation des événements | L’inspection de l’état qui évolue |
Le cycle commun
NEWPUBLISHEDASSIGNEDDELIVERED
Cycle commun aux deux versions, dans cet ordre. Ce projet compare des modèles sur un même workflow, sans conclure qu’une technologie est meilleure dans l’absolu.
Ce que j’en retiens.
Pour ce workflow, l’état d’une commande est plus simple à inspecter en MongoDB pendant qu’il évolue, là où Redis rend la propagation des événements explicite. Aucune des deux n’est meilleure que l’autre dans l’absolu.