Architecting a Food/Grocery Ordering system📝
Demystifying Layered, MVC, and Microservices for Scalable Systems.
1. The Maze of Architecture (Behind the Tap) 🌐
Ever wondered how a simple tap on your favourite delivery app translates to hot food at your door? The instantaneous experience hides a sophisticated organisational structure designed for massive scale, speed, and reliability.
Architecture isn’t about guessing a specific company’s design; it’s about mastering universal patterns that solve problems like managing complex codebases and scaling teams. We’ll walk through the essential patterns — from organising a single file to deploying hundreds of independent services — using the development of a major ordering app as our guide.
2. Foundation 1: The Layered Architecture (Organising One Service)🏗️
While building any application, the first challenge is organising your code. Layered Architecture solves this by enforcing a strict separation of concerns into horizontal layers.
Analogy: Think of a Restaurant Kitchen. Each station has a specific job and only communicates with the station directly above or below it.
In our ordering app, the layers would look like this:
| Layer | Responsibility | Example (The Order Request) |
| Presentation | Handles the UI and user input. | The mobile app screen, or a Next.js component rendering the cart. |
| Application | Orchestrates the flow; manages transactions. | The code that coordinates calls between the Business and Persistence layers. |
| Business/Domain | Contains the core business rules. | calculateDeliveryFee(), applyPromocode(), checking coupon eligibility rules. |
| Persistence | Translates data requests to the database. | The code using Prisma or Drizzle to run the INSERT or SELECT statement. |
Key Takeaway: This structure ensures the core business rules are isolated from database code and the UI, making the application testable and maintainable.
3. Foundation 2: Model-View-Controller (MVC) (Structuring a Feature) 🧩
Model-View-Controller (MVC) is the design pattern that structures a single feature(Checkout screen) within the Presentation and Application layers.
| MVC Component | Layered Placement | Role in the "Checkout" Feature |
| View (V) | Presentation Layer | Design and state management: The displayed cart total, delivery address input fields. |
| Controller (C) | Application Layer | Input Handler / Coordinator: The API route or function that receives the "Place Order" request. |
| Model (M) | Business/Persistence | Core Logic & Data: The code that defines the rules and manages data. Is cart eligible for coupon |
The Crucial Separation: Controller vs. Model
This split defines architectural quality, particularly in validation:
Controller Responsibility: Input Validation (The “Syntax Check”). The Controller performs checks on the request format using tools like Zod. If a field is missing or the input is malformed, it rejects the request immediately.
Model (M) Responsibility: Domain Validation (The “Business Rules Check”). The Model handles checks requiring business context:
Coupon Eligibility: E.g., Is the cart value over ₹500 to be eligible for N coupons?
Payment Rules: E.g., Can a specific type of credit card be used against a particular coupon code?
In practice, the Model is typically split into two modules (classes or services):
Business Service: Holds rules and domain validation (
calculateTax,applyPromocode).Data Repository (Persistence Layer): Handles all database interactions (
saveToDB,loadUser).
4. Level Up: Microservices (The Distributed Ecosystem) 🚀
To handle the demands of millions of users, the ordering app cannot rely on a single-layered application (Monolith). It must transition to Microservices Architecture.
Analogy: We move from one large kitchen to a Food Court where specialised “stalls” (Microservices) operate independently.
A microservice is a small, autonomous application focused on a single business domain, or Bounded Context.
Microservices Breakdown by Domain:
| Microservice Domain | Responsibility |
| Catalogue Service | Manages all menu items, pricing, restaurant details(Owns the Catalogue Database) |
| Order Service | Manages placing, tracking, and cancellation of orders (Owns the Order Database). |
| Search Service | Provides lightning-fast item lookups (feeding an Elasticsearch index). |
Core Principle: Event-Driven Architecture (EDA)
Services cannot share databases. They communicate asynchronously using Events.
Event Publisher: The Catalogue Service (using a
afterUpdatehook, similar to those in Keystone or Payload CMS) publishes aMENU_UPDATEDEvent to a central Message Broker (e.g., Kafka).Event Subscriber: The Search Service subscribes to this event, fetches the updated data via the Catalogue’s public API, and updates its Elasticsearch index.
This loose communication is essential for large-scale resilience.
5. The Two “Cops” Analogy: Gateway vs. Controller🚨
Understanding the roles of the two distinct coordinators is key to the microservices flow:
| Role | Analogy | Component | Logic Focus |
| External Coordinator | Traffic Cop | API Gateway | Checks if you are allowed to enter the system (Authentication), and directs traffic (Routing). No business logic. |
| Internal Coordinator | Elevator Guide | Controller/Application Layer | Sits inside the specific service. Checks if your ticket (data) is valid (Input Validation) and manages the internal business flow. |
6. Putting It All Together: A Complete Order Flow
Trace the “Place Order” request through the entire system:
User (View) clicks “Place Order.”
Request hits API Gateway (Traffic Cop): Authenticates, routes to Order Service.
Order Service’s Controller (Elevator Guide) receives request, validates input format (Zod/Yup).
Controller calls Order Service’s Business Logic (Model): Runs rules like coupon eligibility, calculates final price.
Business Logic calls Persistence Repository (Model): Uses Prisma/Drizzle to
saveOrder()to its private DB.Order Service publishes
ORDER_PLACEDevent.Logistics Service and Notification Service subscribe and react accordingly.
7. Conclusion: Building the Next Generation
You’ve moved from understanding how to organise a single function to mastering the architecture that governs the world’s largest digital systems. Architecture is not a destination; it’s a framework for making informed decisions about isolation, scaling, and maintainability. Mastering the strict boundaries between Layers, the clarity of MVC roles, and the independence of Microservices sets you up to build the next generation of scalable applications.
AI used for content editing and image generation