In today’s fast-paced digital restaurant ecosystem, scalability and modularity are non-negotiable. That’s why our team is engineering Bivy Restaurant Microservices — a backend system powered by FastAPI (Python) and NestJS (TypeScript) to streamline restaurant operations.
As a core backend contributor, I took ownership of:
✅ Designing critical parts of the Entity-Relationship Diagram (ERD)
✅ Leading the User Service (authentication + RBAC)
✅ Architecting the Menu Service (dynamic categorization + inventory sync)
In this article, I’ll walk you through:
📐 My ERD design process
🛠 The microservices I own
🧭 Key technical decisions & what’s coming next
- 🧩 Designing the Database: My ERD Contributions
A well-designed database is the heartbeat of any microservice architecture. Here’s how I approached Bivy’s schema design.
👤 A. User Service Schema
The Challenge:
We needed secure authentication + flexible role management for admins, staff, and customers.
My Solution:
Built a normalized schema with USER and USER_ROLE tables
Designed it to be JWT-ready and role-extensible
erDiagram
USER {
int id PK
string email
string password_hash
string name
int role_id FK
}
USER_ROLE {
int id PK
string name
}
USER ||--o{ USER_ROLE : "has"
Why It Works:
✔ Passwords are stored using bcrypt hashing
✔ Roles are decoupled, enabling easy future expansions (like moderators or vendors)
🍽 B. Menu Service Schema
The Challenge:
Restaurants need menus that evolve — with categories, pricing, and availability — all while syncing with inventory without tight coupling.
My Solution:
Designed MENU_ITEM and CATEGORY tables
Introduced available flag for toggling visibility without touching inventory directly
erDiagram
MENU_ITEM {
int id PK
string name
float price
int category_id FK
bool available
}
CATEGORY {
int id PK
string name
}
MENU_ITEM }|--|| CATEGORY : "belongs_to"
Benefits:
✔ Fully decoupled from inventory DB
✔ Filtering is index-optimized for better performance
🔗 C. Cross-Service Collaboration
To maintain modularity, we ensured services communicate via event-driven architecture instead of direct DB joins.
Examples:
Orders reference both user_id and menu_item_id
Inventory syncs availability via Kafka events
- 🚀 Microservices I Lead
🔐 A. User Service – FastAPI + JWT
Stack: Python, FastAPI, PostgreSQL, JWT
Core Features:
Secure Login/Registration
Role-Based Access Control (RBAC)
User profile endpoints
🍔 B. Menu Service – Dynamic & Real-Time
Stack: Python, FastAPI, Redis (caching), PostgreSQL
Core Features:
Dynamic menu categories
Real-time item availability toggling
AWS S3 image upload support
Workflow Example:
Admin adds a new item via /menu/items
Menu service emits Kafka event to inventory
If stock is available, item is flagged available=True and shown on the customer app
- 📍 Roadmap Ahead
🧭 User Service
[ ] OAuth2.0 integration (Google, Facebook)
[ ] Passwordless login via magic links
🧭 Menu Service
[ ] Redis caching for fast menu queries
[ ] Seasonal menu activation (based on time or promo windows)
🧭 DevOps Goals
[ ] Kubernetes Helm Charts for scalable deployment
[ ] Prometheus + Grafana for monitoring
🧠 Final Thoughts
By prioritizing clean ERD design, modular services, and event-driven architecture, Bivy is built to scale. This system will power:
💡 10,000+ concurrent users
⚙️ Zero-downtime deployments
🔄 Real-time menu updates across all customer touchpoints
What I Learned:
The power of database-first thinking
The value of loose coupling between services
The necessity of security-by-default principles
💬 Let’s Talk!
Have you ever built or contributed to a restaurant backend system?
How did you handle user roles, menu changes, or inventory sync?
Let’s discuss in the comments — I’d love to learn from your experience too.
📡 Connect with Bivy Tech
🟦 X (Twitter)
Top comments (0)