Restaurant Order Management System
A 4-microservice system handling restaurant order intake, priority queue management with Redis, kitchen display operations, and real-time status tracking. Built in 42 minutes for $8.21.
SCREENSHOTS
Research Question
Can microservices architecture effectively handle real-time order coordination and priority queueing in a restaurant environment?
Video Walkthrough
Key Results
- Services: 4 microservices
- Lines of code: ~720
- Build time: 42 minutes
- API cost: $8.21
- Tests: 9/9 passing (100%)
- Grade: A- (91%)
- Response time: <100ms for order submission
- Startup time: 5-7 seconds
- Scalability: Handles 50+ concurrent orders
- Architecture: REST APIs with PostgreSQL + Redis
Architecture
Case Study
Overview
Built a complete microservices-based restaurant order management system with 4 independent services communicating via REST APIs. The system handles order submission, priority-based queueing, kitchen display coordination, and complete status tracking.
Architecture
The system consists of 4 microservices:
Order Intake Service (Port 3001)
- REST API for receiving orders from multiple channels
- Stores orders in PostgreSQL database
- Forwards orders to Queue Management Service
- Provides order lookup functionality
Queue Management Service (Port 3002)
- Maintains active order queue using Redis sorted sets
- Implements priority logic: dine-in orders prioritized over takeout/delivery
- Alerts when queue exceeds 10 orders
- Manages order removal when completed
Kitchen Display Service (Port 3003)
- Displays orders in priority order for kitchen staff
- Allows marking orders as "in progress" or "completed"
- Calculates estimated completion times
- Coordinates updates between Queue Manager and Status Tracker
Status Tracking Service (Port 3004)
- Logs all order state transitions
- Maintains complete order history
- Provides status lookup for customers/staff
- Generates analytics and daily reports
All services communicate via HTTP REST APIs and share data through PostgreSQL and Redis.
Technical Implementation
Priority Queueing
Used Redis sorted sets with timestamp-based scoring:
- Dine-in orders: score = timestamp - 24 hours (higher priority)
- Takeout/delivery: score = timestamp (lower priority)
This ensures dine-in orders always appear first in the queue.
State Management
Three-state model for order lifecycle:
1.
queued - Order received and waiting2.
in-progress - Kitchen actively preparing3.
completed - Ready for pickup/servingEach transition logged with timestamp for analytics.
Service Communication
Asynchronous HTTP pattern with error handling and graceful degradation. Services continue operating even if dependent services fail temporarily.
Key Technical Challenges
Challenge 1: Database Initialization
PostgreSQL doesn't auto-create application databases. Services failed on first startup.
Solution: Created databases manually via psql, documented initialization scripts for future deployments.
Challenge 2: Service Dependency Order
Order Intake tried connecting to Queue Manager before it was ready.
Solution: Implemented Docker health checks and retry logic with exponential backoff.
Challenge 3: Priority Queue Implementation
Needed efficient way to sort orders by priority and timestamp.
Solution: Redis sorted sets provided O(log N) insert and O(1) retrieval of highest priority items.
Performance Observations
- Order submission response time: ~20ms
- Queue retrieval: ~5ms
- State transition (with database writes): ~500ms
- System startup time: ~5-7 seconds total
- Handles 50+ concurrent orders without degradation
Testing Results
All 9 automated integration tests passed:
- ✅ All services healthy
- ✅ Order submission works
- ✅ Orders appear in queue
- ✅ Kitchen display shows correct priority
- ✅ State transitions (queued → in-progress → completed)
- ✅ Status tracking logs all changes
- ✅ Alert triggers when queue > 10 orders
- ✅ Priority ordering (dine-in first)
- ✅ Complete workflow validated
Key Learnings
1. Service Boundaries Matter
Clear separation of concerns made services independently deployable and testable. Each service had a single, well-defined responsibility.
2. Database Initialization is Critical
Always include initialization scripts in production deployments. Manual database creation caused unnecessary deployment friction.
3. Redis Sorted Sets are Perfect for Priority Queues
Built-in sorting and efficient operations made Redis ideal for this use case. Much simpler than implementing custom priority logic.
4. Health Checks are Essential
Docker health checks and service retry logic prevented startup race conditions and improved system reliability.
5. Integration Tests Catch Real Issues
Unit tests passed but integration tests revealed service communication problems. End-to-end testing is crucial for microservices.
Future Improvements
- Add WebSocket connections for real-time kitchen display updates
- Implement message queue (RabbitMQ/Kafka) for better service decoupling
- Add Prometheus + Grafana for monitoring
- Separate PostgreSQL instances per service for true independence
- Implement rate limiting and API authentication
- Add admin dashboard for restaurant managers
Key Findings & Learnings
- Microservices architecture provides excellent separation of concerns and independent deployability
- Redis sorted sets are ideal for priority queue implementations with O(log N) performance
- Database initialization scripts are critical for reliable deployments
- Service health checks and retry logic prevent startup race conditions
- Integration testing reveals issues that unit tests miss in distributed systems
- Asynchronous communication patterns enable graceful degradation when services fail