Delivery System Redis ↔ MongoDB
One lifecycle. Two ways to handle events.
One delivery workflow implemented twice, to compare event propagation against access to a state that keeps changing.
Backend · Events · Individual project · 2025
- Python
- Redis
- MongoDB
- Git
- Bash
The starting point.
Compare event propagation and persistent state by implementing the same order lifecycle with Redis and MongoDB.
What I built.
My own contribution to the project.
Individual project. Designed and built alone.
Two lifecycle implementations
A customer, a manager and a driver move one order along a single lifecycle. One version rests on Redis Pub/Sub and explicit structures. The other on a MongoDB order document observed through Change Streams.
Two approaches to the same problem.
The customer, manager and driver move the same order forward. What differs is how events propagate and how state is read.
Scroll the table horizontally to read all columns.
| Comparison point | Redis | MongoDB |
|---|---|---|
| Mechanism | Pub/Sub | Change Streams |
| Organisation | Explicit structures and published events | Order document observed as it is updated |
| What this version highlights | Event propagation | Inspecting changing state |
The shared lifecycle
NEWPUBLISHEDASSIGNEDDELIVERED
Shared lifecycle in both versions, in this order. The project compares models on one workflow without claiming that either technology is better overall.
What I learned.
For this workflow, MongoDB makes an order’s state easier to inspect while it changes, and Redis makes event propagation explicit. Neither one is simply better than the other.