Microservice-Based Grocery Ordering System
Auth, users, and orders as three independent Flask services — built to learn where distributed systems actually hurt.
- Period
- 2025
- Role
- Sole engineer — service boundaries, DevOps, observability
- Team
- Solo
- Status
- Live on GitHub
3
Independent services — auth, user, order
Health checks
On every service, with performance metrics
One command
CLI utilities to run, inspect, and validate
The problem
Everyone can recite the arguments for microservices. Far fewer people have felt the cost of them — the debugging across process boundaries, the logs scattered over three containers, the moment one service is healthy and the system still is not. I wanted that experience deliberately, on a domain simple enough that the architecture was the only hard part.
What I built
- 01 Split a grocery ordering domain into distinct auth, user, and order services in Python and Flask, each owning its own concerns and its own MySQL persistence.
- 02 Set up Dockerised environments with docker-compose so the whole system comes up together and can be torn down just as fast.
- 03 Added centralised logging, health checks, and performance metrics, because the first thing you lose when you split a monolith is the ability to see what happened.
- 04 Wrote command-line utilities to manage services, tail logs, and validate system behaviour without clicking through anything.
Hardest part
Observability, and it was not close. A single-process app tells you what went wrong for free. Three services tell you nothing until you make them — the failure shows up in one container as a timeout while the actual cause sits in another. Centralised logging and health checks were not extras I added at the end; they were what made the system debuggable enough to keep working on.
Outcome
A running distributed system with the operational tooling to go with it, and a much more concrete opinion about when service boundaries are worth their overhead — which is a lot less often than the blog posts imply.
I built the monolithic version of a comparable system first, on purpose, so that I would have something to compare against. That pairing taught me more than either project would have alone.
The honest conclusion: the architecture buys you independent deployment and costs you every debugging convenience you had. On a small team, that trade is often a bad one. Knowing precisely which convenience you are giving up is the part worth having.