How to practise system design without AI help
Why AI-assisted design practice quietly fails
Ask a chatbot to design a URL shortener and you will get a tidy, plausible answer in seconds. Reading it feels like learning. It is not, for the same reason that reading a chess game is not playing one. The skill in a design round is not knowing the final architecture; it is producing one from a vague prompt, under questioning, while someone watches. The part an assistant does for you, deciding what to ask and what to trade away, is the part you are being tested on.
So the rule for practice is simple: you produce the design first, on paper, from nothing. Only afterwards do you compare it with anything. A written reference answer is useful as a mirror. It is harmful as a crutch.
High-level and low-level design are different skills
High-level design (HLD) is about components and data flow at scale: which services, which stores, where the queue goes, how it fails. Low-level design (LLD) is about the code shape of one component: classes, interfaces, state, concurrency. Loops often include one of each, and people who have only practised HLD are surprised by how much precision LLD wants.
Practise them separately. A good LLD problem has a small, testable core: a rate limiter, a cache with eviction, a priority scheduler, a prefix store. You can write it, run it, and know whether it works. That is why several of the algorithm problems on this site, like Suggest as you type and Serve by urgency, double as LLD warm-ups.
A forty-five-minute routine you can run alone
- Minutes 0 to 5, requirements. Write the functional requirements as short sentences. Then write the non-functional ones: scale, latency, availability versus consistency, durability. If you did not ask a clarifying question, you are guessing.
- Minutes 5 to 10, numbers. Estimate requests per second, storage per year, and read-to-write ratio. Round aggressively. The point is not accuracy, it is knowing whether you need one database or many.
- Minutes 10 to 20, data model and API. Name the entities, the keys, the access patterns, and the two or three endpoints that matter. Choose the store because of the access pattern, and say why.
- Minutes 20 to 35, the design. Draw the components, follow one write and one read end to end, then find the bottleneck and fix it.
- Minutes 35 to 45, failure and trade-offs. What happens when a node dies, a queue backs up, a cache goes cold, a region is lost? Name at least two decisions you made and what you gave up for them.
Use a timer. Interviews do not wait for you to feel ready, and the discipline of reaching failure handling before the clock ends is itself a skill most people lack.
Make trade-offs explicit
The most common weakness in a design answer is a list of technologies with no reasons. Replace every noun with a decision. Not "we use Kafka" but "we put a queue here because writes spike and the consumer can fall behind without losing events; the cost is that reads can lag, which the product tolerates."
- Consistency versus availability: which one does this product need when the network partitions?
- Latency versus cost: what do you precompute, and how stale can it be?
- Simplicity versus scale: what is the simplest thing that survives ten times today’s load, and what would make you redesign?
- Push versus pull, synchronous versus asynchronous, one store versus several.
Get a signal that is not applause
Practising alone has a real problem: nobody tells you what you missed. Two things help. First, build a checklist from real requirements: did I handle duplicates, did I say what happens on retry, did I size the data, did I name a failure mode. Second, find a way to be tested against concrete questions rather than general impressions.
That second point is how Unaided approaches system design. The practice is objective: you commit to numbers, choices and orderings, and they are checked against concrete requirements covering scale, failure, data model and trade-offs. There is no conversational model grading how convincing you sound. It will not replace talking a design through with a senior engineer, which is worth doing before a real loop, but it tells you which areas you are actually weak in.
Data-structure fluency is design fluency
A surprising amount of design is data-structure choice. A leaderboard is a heap or a sorted structure; autocomplete is a trie; a scheduler is a priority queue; a multi-tenant store is a keyed namespace. Problems like Live top-k total and Prefix-scoped store are small versions of components you will be asked to place in a larger diagram. If the small version is automatic, the large conversation gets easier.
Where to go from here
Pick three systems a week, run the routine on each, and write down the one thing you missed every time. After a month that list is your real study plan. If you want the daily structure, the clock and the checking handled for you, start here. Details of passes are on the pricing page. For the coding rounds that sit next to the design round, see our 15-day preparation plan.