Hello! I’m Firdaus Al Ghifari (Alghi), a full-stack software engineer in Japan. Recently, I came across a system design problem that got me thinking: how would you build a nationwide food review app for Indonesia’s Makan Bergizi Gratis (MBG) program, also called Reviu MBG, where students and teachers submit daily feedback on their catered meals?
\nThe feature set is small, but the user base is huge. If tens of millions of people could submit a review at roughly the same time, what would the architecture look like? In this article, I’ll walk through how I’d approach that problem using the 4-step system design framework from Alex Xu’s book, System Design Interview – An Insider’s Guide.
\nPicture yourself in a system design interview. The interviewer asks you to design a food review app used by Indonesian students and teachers to rate their daily school catering.
\nSystem design questions often start with vague requirements. That can feel overwhelming at first, but the key is to stay calm and ask the right questions before jumping into solutions.
\nHere is an example dialogue for figuring out the requirements:
\nAt this point, the scope is clear: a simple web app for optional daily meal reviews, shared via QR codes on food packages, serving a nationwide user base.
\nThis step has two parts: sketch a simple system blueprint, then run back-of-the-envelope calculations to check if the design can handle the load. Because the user base is so large, I prefer doing the capacity estimation first. It helps us pick the right architecture early.
\nUsing recent demographic data, let’s round the potential user base to 60 million. Since reviews are optional, I’ll assume 15% of users submit one review per day. For a worst case, I’ll also assume most of those submissions happen during the lunch hour of 12:00–13:00 WIB (Western Indonesian Time).
\nDaily review volume:
\nPeak write load (worst case within the lunch hour):
\nEach review submission is a write operation, so the system must handle roughly 10,000 writes per second (WPS) at peak.
\nTo put this in perspective, Visa processes a global average of about 2,000 transactions per second (TPS), with network capacity designed for peaks above 83,000 TPS. A nationwide lunch rush is surprisingly close to the scale of a global payment network. (Note: WPS can be several times higher than TPS for the same user activity, since a single user action may trigger multiple database writes.)
\nThe data model is structured and relational (Catering Vendor → Daily Campaign → Food Review), so a relational database is a good fit. I’d choose PostgreSQL for its reliability and solid concurrent-write performance.
\nThat said, a standalone PostgreSQL instance typically handles up to around 2,000 concurrent writes per second before it starts to slow down. At 10,000 WPS, writing directly to the database won’t work.
\nThe solution is to separate the client write path from the database using an event-driven architecture:
\nThis queued, batched approach handles the lunch-hour spike without needing database sharding.
\nOne more thing to consider: image uploads. With an event-driven queue in place, we should not push large binary payloads through the message broker because that would slow things down. Instead, photos should be uploaded directly to object storage (S3) before the review text is submitted.
\nHere is the resulting high-level architecture:
\nAfter presenting the high-level design, an interviewer may ask you to go deeper on specific parts like data models, storage estimates, or implementation details. At this stage, work with the interviewer to focus on what they care about most.
\nFor this walkthrough, I’ll focus on the Review data model and how much storage the photos need.
\nThis table stores user reviews for each daily meal package.
\nreview_id (UUID, Primary Key), 16 bytes: Client-generated unique ID to prevent duplicate submissionscampaign_id (UUID, Foreign Key), 16 bytes: Links the review to a specific daily catering campaignrating (SMALLINT), 2 bytes: Rating on a 1–5 scalecomment (TEXT), ~200 bytes: Optional free-text review (average length)photo_url (VARCHAR), ~100 bytes: Optional URL pointing to the image in S3created_at (TIMESTAMP), 8 bytes: When the review was createdupdated_at (TIMESTAMP), 8 bytes: When the review was last modifiedEach row is roughly 350 bytes. Rounding up to 500 bytes per row (including index overhead and page padding):
\nAssuming 20% of reviews include a photo, and the frontend compresses images to an average of 300 KB before upload:
\n130 terabytes per year is a good reason to keep photos in object storage, not the database. It also shows why we need lifecycle policies, like moving photos older than 90 days to cheaper tiers such as S3 Infrequent Access or Glacier.
\nCost estimation is uncommon in live interviews, but it helps us understand the real cost of our design. Here’s a rough monthly budget for the review system.
\ndb.r6g.large cluster ≈ $360/monthStudents only download the lightweight web app and small menu metadata (~50 KB per session):
\nCombining the layers above:
\nThe review feature is the heaviest part of the system. Adding supporting features like admin panels, vendor dashboards, and campaign management might push the total cost roughly 50% higher, landing around ~$9,000/month (~Rp 162 million at ~Rp 18,000/USD).
\nWe designed for a scenario where up to 60 million users could submit reviews during a nationwide lunch rush. In practice, the real-world setup may be much simpler. If students never access the app directly and only school admins or catering vendors log the feedback, traffic drops sharply, and so does the server bill.
\nDesigning for a nationwide lunchtime spike sounds scary at first, but clear steps make it easier to handle. By estimating capacity early, choosing PostgreSQL for relational data, and using a message queue to handle traffic spikes and batch writes, we can handle ~10,000 WPS without sharding a database.
\nThe rough monthly cost for this scale comes to about $9,000 (~Rp 162 million) for a production-ready nationwide system, but the actual bill depends on who submits reviews and when.
\nThe next time a system design question feels overwhelming, don’t panic. Ask questions, estimate capacity, propose a simple architecture, and go into the details with your interviewer.
\nThank you for reading this article 😄. If you have any questions or want to discuss system design, feel free to reach out via LinkedIn or my other social media platforms.
\nHappy coding!
","fields":{"slug":"/2026-06-14-food-review-app-system-design/"},"frontmatter":{"title":"System Design Case Study: Scaling the Nationwide Food Review App (Reviu MBG)","date":"June, 14 2026","description":"Learn how to use a practical 4-step system design framework to architect an event-driven, cost-effective food review platform capable of handling a massive 10,000 writes-per-second lunchtime rush.","category":"system-design","author":"Firdaus Al Ghifari","topimage":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAsTAAALEwEAmpwYAAACqklEQVQoz02RWXMaRxRG+ZP5I/kXSR5kP8SJIhtbqkpEpFhSWVgpRcIYjDAgS2IdAWIZGGaBWREzrINPWrgqlYevbndV97mnb0fCuUM4t1nNbNYLB39ioNkKqj1Adw0US6Xv6KjjEYpr0vMsemOHtm1iBD5eGOIuQ5zFapPIBraBfgMHgUm+fkeqXCBRzJOsfCF+fUWydsvfxQJnxWsyTYmLShE9CPBW6/9gzlIAn6wWvsHsUWMdjlmvA0bCSNb7dJ5i9JEGXdqWwb0+oGFotM0RPdfBXT3ZrRiv/gf8unTxJi6qrtJoSCgDhWU453EqLgQOiinjuF1cT2GyeMReLrBEBv6UWbjCmi7pulPCr0+my29AXXSUBxq1aoVW6wF/5jOw+pQ7NSqNLJnMPqXMS+RWGkmc7XouNdPFEbVSu+fzTQnXtje2mxmGAhqGj8JsgmH2sCYjvMVE2Ey5b99xvvM97374jnTmkJbvo8+njBYz/NWSjtyh1W3j+QHj9ZrIam6hNCtU8lm6DzUsdyieXqE77JMr3tIedskko+QudxgYdUq9Hg1dQ51NaeoGqudRqEhkb0vok4BIX+nwYi/G2+0El7/GRd1n69kLviRznPwYpdquIjcSBOaNmNGIeCxO6n0KSXzOq+ev+JD4RGz7d46juxTOz4gMxS/+tH3Iu733/HGQ4PQsze7uEcWixOvnf6JNNHpqlb5ew57pnJymOTm85MEc8ublMZ+vy2xt7fM6GuPi7TERW6nyJnrA5cFfxGKnXH1IUv6UoVHN88vPvzE268j9W1ryDe5I4iotmh6dMGoXKX28QC7nSJzG2dk74vyfj0S8fpFOMYvVvsFu5lFLKQwpI3JFp5BgolWZGvciEoGI3rhmVM+i1QsYzWs0sVfFWr5LoUk5/gVzjA24Nud46QAAAABJRU5ErkJggg==","aspectRatio":1.829268292682927,"src":"/static/fdda79fcaec3515a1e63c4f629114311/73f08/cover_image.png","srcSet":"/static/fdda79fcaec3515a1e63c4f629114311/57fc3/cover_image.png 300w,\n/static/fdda79fcaec3515a1e63c4f629114311/f8eb5/cover_image.png 600w,\n/static/fdda79fcaec3515a1e63c4f629114311/73f08/cover_image.png 1200w,\n/static/fdda79fcaec3515a1e63c4f629114311/29036/cover_image.png 1408w","sizes":"(max-width: 1200px) 100vw, 1200px"}}},"topimagedesc":"Image generated by Gemini"}}},"pageContext":{"slug":"/2026-06-14-food-review-app-system-design/","previous":{"fields":{"slug":"/2025-07-31-handling-japanese-numeric-ux/"},"frontmatter":{"title":"Handling Japanese Numeric UX in React with React Hook Form & Zod","category":"frontend"}},"next":null}},"staticQueryHashes":["2742190585","642825376"]}