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 Apache 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, PostgreSQL,
Core Features:
Dynamic menu categories
Real-time item availability toggling
Image upload support (S3 integration)
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
[ ] OAuth 2.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
[ ] Monitoring via Prometheus + Grafana
π§ 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
π¦ Follow us on X (Twitter)
π¦ Connect on LinkedIn
Top comments (0)