01 — Machine Learning
← back

project_01

Sunakku

snack ordering platform — queue-based, real-time, high-throughput

● LiveBullMQ / QueueNext.js + Node
Overview

A real-time snack ordering system built for high-throughput cafeteria environments. Order intake is fully decoupled from processing — the REST API stays responsive under peak kitchen load while BullMQ workers handle fulfillment asynchronously. Redis caching eliminates 94% of redundant DB reads, and atomic locks prevent race conditions on limited-stock items before enqueuing.

Problem

Cafeteria POS systems fail under peak load — multiple users race to order the last item simultaneously. Synchronous flows either over-block throughput or allow overselling. We needed guaranteed inventory consistency without sacrificing API response time.

Engineering Challenges
01.Race conditions on low-stock items solved with Redis SET NX atomic locks before any enqueue operation
02.Worker crashes mid-job required idempotency keys on all order mutations to prevent duplicate fulfillment
03.Cache invalidation for menu updates — chose pub/sub over TTL-only for near-instant propagation
Key Decisions
→BullMQ over raw Redis — built-in retry logic, job prioritization, and ops dashboard out of the box
→Redis 80s TTL on menu data eliminated 94% of redundant DB reads at peak lunch windows
→Prisma over raw SQL — version-controlled migrations, far less deployment friction
→Stateless JWT + Glauth — auth service scales horizontally with zero session store overhead
← prevGatekeepersourcenext →Velox
Stack
Next.jsNode.jsExpressPostgreSQLRedisBullMQPrismaDockerNginx
Architecture
Web AppNext.jsAuthJWT / GlauthREST APIExpressRedis CacheTTL 80sOrder QueueBullMQPostgreSQLPrisma ORMhttpenqueuereadpersist
Key Features
◆Live inventory sync — Stock levels update in real-time across all clients via WebSocket on every order commit
◆Atomic order locking — Redis SET NX prevents two users from claiming the last item — lock released if queue job fails
◆Queue-based processing — BullMQ decouples intake from fulfillment — API stays sub-120ms even when workers are backlogged
◆Smart cache layer — Redis 80s TTL with pub/sub invalidation eliminates 94% of Postgres reads at peak
Metrics
<120msAPI Response
2,400+Orders / Day
94%Cache Hit Rate
99.9%Uptime