Easy System Design Interview Questions: 10 Practice Problems for Junior Engineers

Most system design question lists are written for people who already work on distributed systems. They open with a ride-sharing platform or a video streaming service, and a junior engineer reading them learns very little, because every paragraph assumes five ideas that were never explained.

This list works the other way around. Every question here can be designed on a whiteboard in 30 to 45 minutes, needs six or seven components at most, and teaches one or two ideas that come back in every harder question you will ever be asked.

One clarification about the word "easy". An easy question is not a question about a small product. It is a question where the difficulty is visible: you can see what the system has to do, and the interesting decision is a single trade-off rather than ten interacting ones. A leaderboard is easy in that sense. A payment ledger is not, even though both of them mostly store numbers.

If you want the classic starter set in a strict learning order, read 10 beginner system design interview questions to master first, which walks through URL shorteners, rate limiters, crawlers, and news feeds as a single progression. The article you are reading now is the companion practice set: ten different problems, picked so that each one drills a different fundamental. Every question below also links to the exact Design Gurus lesson that solves it step by step, so you can attempt the question first and then check your answer against the full walkthrough.

What Interviewers Actually Grade in an Entry-Level Round

Nobody expects a new graduate to produce a correct global architecture. The interviewer is checking a much smaller list:

• Do you ask what the system must do before you start drawing?
• Can you name the data you store and the operations that touch it?
• Do you choose a database for a stated reason instead of a habit?
• Do you know what a cache, a queue, and a replica each buy you, and what each one costs?
• When a component fails, can you say what the user sees?
• Can you explain your reasoning out loud in an order someone else can follow?

Every question below is a vehicle for those six skills. Treat the architecture as a by-product. The reasoning is the answer.

If you are still assembling the vocabulary, start with the system design interview guide and the system design fundamentals primer, then come back to this list.

The Concepts These Ten Questions Cover

Ten questions, ten different building blocks. Nothing on this list repeats a lesson another item already taught.

How to Practice One Question

Give yourself 45 minutes and follow the same loop every time:

1. Write down the three features the system must have, and one number for scale.
2. List the data you store, and the two or three API calls that touch it.
3. Draw the simplest architecture that serves the main feature end to end.
4. Find the first component that breaks when traffic grows ten times.
5. Fix that one component, and say what your fix costs.
6. Say what the user sees when each remaining component fails.

Then, and only then, look up a reference solution and compare. The gap between your version and the reference is your study list for the week.

1. Design a Blogging Platform

Users publish posts, edit them, read them, and leave comments. Assume a few thousand writers and a few hundred thousand readers.

The shape is a load balancer, a small pool of application servers, a relational database holding users, posts, and comments, object storage for images, and a cache in front of rendered posts. Reads outnumber writes by a wide margin, so you add one or two read replicas and send every page view to them.

What it teaches. Read-heavy workloads, primary and replica replication, cache-aside, and cursor pagination for a list of posts.

The trade-off to say out loud. Replicas lag behind the primary. An author who publishes a post and immediately reloads the page may hit a replica that has not received the write yet, and the post looks lost. The standard fix is read-your-writes: route a user's own reads to the primary for a few seconds after they write.

Common beginner mistake. Sharding on day one. At this scale one primary with two replicas is the correct answer, and saying so is a point in your favor, not against you.

Study next. Replication, load balancing, and caching are covered end to end in Grokking System Design Fundamentals. The closest full walkthrough of this shape is Designing Pastebin, a small write path in front of a heavy read path, and Read Heavy vs Write Heavy System explains how to tell the two apart.

2. Design an Image Hosting Service

Users upload an image, get back a link, and share it. Thumbnails are generated for previews.

The client should not send the image bytes through your application servers. Instead, the server hands the client a presigned upload URL, the client uploads straight to object storage, and the server stores a metadata row: image id, owner, storage key, size, and created time. A content delivery network sits in front of the storage bucket so that popular images are served from a location near the viewer. A background worker picks up an event after each upload and writes the thumbnail sizes.

What it teaches. The split between bulk data and metadata, why object storage beats a database for binary files, what a CDN actually does, and asynchronous post-processing.

The trade-off to say out loud. Generating thumbnails during the upload request makes the upload slow but the image immediately usable everywhere. Generating them in the background makes the upload fast but forces the interface to show a processing state for a second or two. Pick one and defend it.

Common beginner mistake. Storing image bytes as blobs in the main database. It works in a demo and destroys your backup and replication story in production.

Study next. Work through Designing Instagram, which is the complete version of this question: uploads, metadata, the content delivery network, and the feed built on top of it. Grokking Scalable Systems for Interviews covers content delivery networks and the scaling steps that follow.

3. Design a Leaderboard

A game shows the global top 100 players and tells each player their own rank. Scores change constantly.

Keep the authoritative scores in your database, and keep the ranking in a sorted set in an in-memory store such as Redis. A score update writes to both. Reading the top 100 is then a single range query on the sorted set instead of a sort over millions of rows.

What it teaches. Choosing a data structure to match a query, cache invalidation, hot keys, and the difference between an exact answer and a good enough answer.

The trade-off to say out loud. The top 100 is cheap. An exact rank for every one of ten million players is not, because the answer changes on every write. A common compromise is exact ranks inside the top slice and a bucketed rank elsewhere, for example "top 5 percent", refreshed every minute.

Common beginner mistake. Running ORDER BY score DESC LIMIT 100 against the primary database on every page load, then adding a cache without deciding when it is invalidated.

Study next. The counting problem underneath a leaderboard is solved step by step in YouTube Likes Counter, which handles the same high write volume and cheap ranked reads. The caching decisions are the ones in caching in system design interviews, and the reusable versions live in System Design Patterns.

4. Design a File Sharing Service

Think of a simplified Dropbox. A user uploads files, the files appear on their other devices, and a link can be shared.

Split every file into fixed-size chunks, for example 4 MB, and hash each chunk. Store the chunks in object storage keyed by their hash, and store the file metadata separately: file name, version, and the ordered list of chunk hashes. Identical chunks are stored once. Each device keeps a cursor into a per-user change log, and syncing means asking for changes since that cursor and downloading only the chunks it does not already have.

What it teaches. Separating metadata from data, content addressing, deduplication, and delta sync.

The trade-off to say out loud. Chunk size. Small chunks deduplicate better and make resumed uploads cheaper, but they multiply the amount of metadata you store and the number of requests per file.

Common beginner mistake. Re-uploading an entire file after a one-line edit, and treating the metadata service as an afterthought when it is the part that actually gets complicated.

Study next. Designing Dropbox is the complete walkthrough, with chunking, the metadata service, and sync covered end to end. The interview framework around it is in Grokking the System Design Interview.

5. Design a Movie Ticket Booking System

Users browse shows, select seats, pay, and receive a confirmation. Two users must never be sold the same seat.

Model each seat of each show as a row with a state: available, held, or booked. Selecting a seat creates a hold with an expiry a few minutes out. Payment confirmation converts the hold into a booking inside a single transaction. A unique constraint on the pair of show id and seat id is the backstop that makes double booking impossible even when your application logic has a bug.

What it teaches. Transactions, row-level locking, unique constraints, expiring reservations, and idempotency on the payment callback.

The trade-off to say out loud. Pessimistic locking holds a row lock while the user decides, which is simple and blocks other users. Optimistic locking lets both attempts proceed and fails the loser at write time, which scales better and requires a graceful failure message. Popular shows favor short pessimistic holds; a quiet catalog favors optimistic.

Common beginner mistake. Checking availability and then writing the booking as two independent steps with no transaction and no constraint. Under load, two users get the same seat.

Study next. This question is solved three different ways across the courses, and reading all three is the fastest way to see how one product changes shape with the interview: Designing Ticketmaster for the architecture, Design a Movie Ticket Booking System for the class-level version, and Case Study: A Ticket Booking Platform for the service boundaries. Grokking Database Fundamentals for Tech Interviews covers the transaction and isolation topics directly, and database design patterns summarizes the modeling choices.

6. Design a Job Scheduler

Users register jobs with a schedule, such as "every hour" or "at 2 AM daily", and the system runs them on time and retries the failures.

Store the schedules in a database with a next run time column and an index on it. A poller wakes up every few seconds, claims the jobs whose time has come, and pushes them onto a queue. A pool of workers consumes the queue, each taking a lease on the job so that a second worker does not pick up the same one. Failures go back on the queue with an exponentially growing delay, and after a few attempts they land in a dead-letter queue for a human to inspect.

What it teaches. Message queues, leases and visibility timeouts, at-least-once delivery, retries with backoff, and idempotency keys.

The trade-off to say out loud. Exactly-once execution is not something you can buy. You get at-least-once delivery plus handlers that are safe to run twice, and saying that plainly is one of the strongest signals a junior candidate can send.

Common beginner mistake. Assuming a job runs once, so the handler sends an email or charges a card without an idempotency key.

Study next. Design a Distributed Job Scheduler (like Cron) walks through this exact system, including the lease and retry mechanics. Asynchronous communication between services, queues, and retry policy are the backbone of Grokking Microservices for System Design Interviews.

7. Design an Online Code Judge

A user submits code, the system runs it against hidden test cases, and returns a verdict such as accepted, wrong answer, or time limit exceeded.

The submission API does almost nothing: it validates the payload, writes a submission row, and puts a message on a queue. Sandboxed workers pull from that queue, run the code in a container with a hard CPU limit, a memory limit, and no network access, compare the output against the expected output, and write the verdict back. The client polls for the verdict or receives it over a push connection.

What it teaches. Request and response through a queue, worker pools, autoscaling on queue depth, timeouts, and treating isolation as a requirement rather than a detail.

The trade-off to say out loud. During a contest, submissions arrive far faster than workers can drain them. You either scale workers up and pay for idle capacity the rest of the time, or you accept a growing queue and tell the user honestly where they are in line. Hiding the delay is the wrong answer.

Common beginner mistake. Running untrusted code in the same process that serves the API.

Study next. Design Code Judging System like LeetCode is the complete walkthrough, sandboxing and all. Read system design failure modes for what happens when the queue backs up, and use the System Design Interview Crash Course if your interview is close.

8. Design a Discussion Forum

Users post links and text, comment in threads, vote, and read a ranked front page. Think of a small Reddit.

Posts and comments live in a relational database. A comment stores its parent id so that a thread can be rebuilt, and deep threads are loaded in pages rather than all at once. Votes are written to their own table and aggregated into a counter on the post rather than counted at read time. A scheduled task recomputes each post's score from its votes and its age, and the front page for each subforum is cached as a list of post ids for a minute or two.

What it teaches. Counters at scale, ranking formulas, caching a list rather than an item, and cursor-based pagination.

The trade-off to say out loud. Vote counts can be live or the front page can be cheap, but not both. Almost every real forum picks near real time: votes are visible to the voter immediately and the ranking catches up within a minute.

Common beginner mistake. Paginating with OFFSET. On page 500 the database still walks the first 500 pages of rows. Paginate with a cursor built from the sort key instead.

Study next. Design Reddit is the full walkthrough, including the comment tree and the ranking job. When fan-out and multi-region reads start to feel comfortable, the rest of the Advanced System Design Interview picks up where this question stops.

9. Design a Parking Lot

This one is different on purpose. It is a low-level design question, which means the interviewer wants classes, interfaces, and behavior rather than servers and databases. Companies use it as a warm-up in the same slot they would otherwise use for architecture, so it belongs on any beginner list.

Model the lot as a ParkingLot that holds Level objects, each holding Spot objects of different sizes. A Vehicle has a size and asks the lot for a spot that fits. Entry produces a Ticket with a timestamp. Exit passes the ticket to a pricing strategy that returns an amount, and to a payment interface that you keep abstract so that cash and card are interchangeable.

What it teaches. Encapsulation, programming to an interface, the strategy pattern for pricing, state transitions on a spot, and the one concurrency concern that matters: two cars must not be assigned the same spot.

The trade-off to say out loud. Where pricing logic lives. Putting it in the ticket is convenient and hard to change; putting it behind a strategy interface adds a class and lets you add weekend rates without touching the lot.

Common beginner mistake. Answering with a database schema. If the question asks for classes, give classes.

Study next. Design a Parking Lot is the class-by-class walkthrough, with the diagrams an interviewer expects to see. The difference between the two interview types is explained in types of system design interviews, and the object-oriented track itself is Grokking the Object Oriented Design Interview.

10. Design a "Because You Watched" Recommendation Row

A streaming app shows each user a row of ten suggested titles, refreshed daily. No machine learning background is required to answer this well.

Every view is written to an event log. A nightly batch job reads the log and counts how often each pair of titles is watched by the same user, which gives you a simple item-to-item similarity score. The top twenty similar titles for each title are written to a key-value store. At request time the serving layer takes the user's few most recent titles, looks up the precomputed lists, removes anything already watched, and caches the resulting row for that user.

What it teaches. The split between an offline path and an online path, precomputation as a latency strategy, freshness against cost, and fallbacks for users with no history, which is the cold start problem.

The trade-off to say out loud. A nightly batch is cheap, simple, and up to a day stale. Streaming updates keep the row fresh and cost far more to build and operate. For a first version, stale is fine, and new users get a popularity-based row instead.

Common beginner mistake. Proposing to train or query a model during the request. Recommendations are precomputed for exactly this reason.

Study next. Design a Recommendation System is the full walkthrough, and Design Feed Ranking is the step up from it. Both are in Grokking the AI System Design Interview, which covers recommendation, ranking, and the serving patterns that come after this one.

A Four-Week Practice Plan

Four questions a week is too many. Two, done properly, is better.

• Week 1. Blogging platform and image hosting. Goal: draw a request path end to end and defend one database choice.
• Week 2. Leaderboard and file sharing. Goal: explain a cache and a data model without hand-waving.
• Week 3. Ticket booking and job scheduler. Goal: talk about correctness under concurrency and failure.
• Week 4. Discussion forum and online code judge, plus the parking lot as a 30-minute warm-up. Goal: hold a full 45-minute conversation without stalling.

Attempt each question cold first. Look at a reference solution second. Then rebuild it from an empty page a day later, which is the step most people skip and the one that actually moves the skill.

When You Are Ready for Harder Questions

Move on when three things are true: you can start any question with requirements instead of boxes, you can name the bottleneck before the interviewer asks, and you can describe what breaks when any single component dies.

At that point, work through the classic progression in 10 beginner system design interview questions to master first, which covers URL shorteners, rate limiters, unique ID generation, autocomplete, web crawlers, notifications, chat, and news feeds in the order that makes each one easier than the last. After that, the complete library of system design interview questions and case studies has the full range, sorted from approachable to genuinely hard.

Frequently Asked Questions

Are these questions actually asked in interviews? Yes, though the wording varies. Ticket booking, parking lot, leaderboard, and file sharing are common at mid-size companies and in first rounds at large ones. The others appear as simplified versions of bigger questions, which is precisely why they are useful practice.

How long should one question take? Forty-five minutes for the attempt, roughly twenty for comparing against a reference, and another thirty a day later to rebuild it from memory. If a first attempt takes three hours, you are researching rather than practicing, and the two are not the same exercise.

Do I need exact capacity numbers? No. You need numbers that change a decision. Knowing that reads outnumber writes a hundred to one tells you to add replicas and a cache. Knowing the exact byte size of a row tells you nothing.

Will a junior candidate even get a system design round? Increasingly, yes, but it is graded as a discussion rather than a design review. Interviewers are checking whether you can reason about a system you have not seen, not whether you have memorized an architecture.

What is the difference between these and low-level design questions? System design questions ask for services, storage, and data flow. Low-level design questions ask for classes, interfaces, and behavior inside one service. The parking lot above is the second kind, and the distinction is covered in types of system design interviews.

Which question should I start with? The blogging platform. It has the fewest moving parts, and every later question reuses its load balancer, database, cache, and object storage.

Start With the Fundamentals, Then the Questions

The reason beginners struggle with system design is rarely the questions. It is that the questions are attempted before the building blocks are understood, so every answer becomes a guess dressed up as a diagram.

Learn the blocks first in Grokking System Design Fundamentals. Practice the ten questions above, one concept at a time. Then move into the full interview framework and the complete problem set in Grokking the System Design Interview.

Ten easy questions, understood deeply, beat fifty hard ones you skimmed.