·8 min read

How I built a food-ordering platform for thousands of daily orders with Next.js and NestJS

Next.jsNestJSArchitectureCase study

I led the build of an online ordering platform for Cheezious, one of Pakistan's fastest-growing restaurant chains. During peak hours it handles thousands of simultaneous orders across multiple branches, coordinating kitchens, delivery riders, and point-of-sale machines in real time. This is the architecture I'd defend, and the decisions I'd make the same way again.

The real problem wasn't traffic — it was coordination

Before the rebuild, every branch ran its own disconnected workflow. A rush at one location was invisible to regional management, and riders were dispatched by phone — slow, error-prone, and impossible to audit afterwards. Raw request volume was solvable with more servers. The hard part was giving one order a single source of truth that the customer, the kitchen screen, the rider app, and the head-office dashboard could all trust at the same moment.

Why Next.js and NestJS, not a MERN monolith

The storefront needs to load fast on cheap phones and rank in search, so Next.js with server rendering was the obvious front end. The backend needed structure that survives a growing team and a growing domain, so I used NestJS: its modules, dependency injection, and DTO validation keep a large API testable instead of drifting into spaghetti. Order data is deeply relational — orders, items, branches, riders, payments — so PostgreSQL was the store of record, with Redis absorbing the read-heavy live dashboards.

I'll be honest about the trade-off: a single-language MERN stack would have been faster to start. But relational integrity for money and inventory, plus SEO on the storefront, are exactly the two things MERN handles worst. I picked per requirement, not per convenience.

Postgres as the source of truth, Redis for the read storm

Every order state transition is written once to Postgres. The live dashboards — kitchen screens, the rider map, the regional queue-depth view — are read-heavy and refresh constantly, so I kept those reads off the write path by caching current state in Redis and invalidating on each transition. The write path stays fast during the dinner rush because it isn't competing with hundreds of dashboards polling for updates.

Real-time without melting the server

Live order tracking runs over Socket.IO. The mistake I see often is broadcasting every update to every connected client. Instead, each branch and each order gets its own room, so a kitchen screen only receives events for its branch and a customer only hears about their order:

@WebSocketGateway({ cors: true })
export class OrdersGateway {
  @WebSocketServer() server: Server;

  // A kitchen screen joins only its branch's room.
  handleConnection(client: Socket) {
    const branchId = client.handshake.query.branchId as string;
    if (branchId) client.join(`branch:${branchId}`);
  }

  // One transition fans out to just the people who care.
  emitOrderUpdate(order: Order) {
    this.server.to(`branch:${order.branchId}`).emit('order:update', order);
    this.server.to(`order:${order.id}`).emit('order:update', order);
  }
}

Rooms turn an O(all clients) broadcast into an O(interested clients) one. That single decision is the difference between a socket layer that survives peak hours and one that falls over.

Handling the dinner rush with queues

Orders don't arrive evenly. They spike at lunch and dinner. Doing slow work — printing to the kitchen, notifying the rider service, syncing the POS — inline with the request would stall checkout exactly when it matters most. So the API's only job at order time is to validate, persist, and enqueue. A BullMQ worker backed by Redis drains the queue with controlled concurrency:

// Checkout stays fast: validate, persist, enqueue, return.
await this.orderQueue.add('process-order', { orderId: order.id }, {
  attempts: 3,
  backoff: { type: 'exponential', delay: 2000 },
});

// The worker absorbs the spike at its own pace.
@Processor('orders')
export class OrderProcessor {
  @Process('process-order')
  async handle(job: Job<{ orderId: string }>) {
    const order = await this.orders.findOne(job.data.orderId);
    await this.kitchen.print(order);      // slow I/O, retried on failure
    await this.dispatch.notifyRiders(order);
  }
}

Retries with exponential backoff mean a flaky third-party POS call doesn't lose an order — it just tries again. The customer already has their confirmation; the rest happens reliably in the background.

Results, honestly stated

The platform handles thousands of simultaneous orders during peak hours across all branches, at 99.9% uptime. Order processing time dropped by roughly 60% and delivery-coordination errors by around 80% versus the old phone-and-spreadsheet workflow. Those are the real figures from the project — I'm not going to invent a rounder number for a headline.

If you're building something similar

  • Give each entity one source of truth. For orders and money, that means a relational database, not a document store you're hoping stays consistent.
  • Keep read-heavy live views off the write path with a cache, so dashboards can't slow down checkout.
  • Scope your real-time layer with rooms from day one — retrofitting it later is painful.
  • Move slow, failure-prone work into a retried queue so the request path stays fast and orders never silently vanish.

If you're planning a platform like this and want someone who has shipped one, that's the kind of work I take on.

Related