mySystemDesign Review: HLD and LLD Practice Roadmaps Without a Verified Judge

mySystemDesign organizes high-level and low-level design preparation through a roadmap, practice list and resource collection. Use those surfaces to choose the next design question you need to resolve. We did not verify an assessed-submission workflow in the public practice view, so a topic marked Done should be treated as personal progress rather than evidence that an independent judge accepted your design.

Start with PracHub’s URL-shortener question with expiration and security and write a requirement that can fail. “Study URL shorteners” is an activity; “an expired code must stop resolving at the declared boundary” is a behavior you can explain and test. This distinction makes a roadmap useful rather than merely satisfying to check off.

Checked November 3, 2026: official interface descriptions, our anonymous public-page inspection and an original local boundary fixture are separated below. We did not submit a design for grading, verify account synchronization or measure hiring outcomes. No independent candidate evidence establishes readiness-score validity. PracHub publishes this review and provides the linked preparation questions.

What the public workspace actually offered

The mySystemDesign site exposed roadmap navigation alongside LLD, HLD, patterns, practice, resources and other preparation areas. Our public view displayed progress counters and topics that could be tracked as not started, active or done.

The practice page listed 28 HLD and LLD exercises at different difficulty levels. Entries included external video or guide links and an option to add a resource. We inspected the list as a curriculum and planning surface; we did not complete every exercise or audit the destination quality of every recommendation.

The URL Shortener entry was an HLD exercise with concepts including short-code generation, a key-value store, redirects, expiration and analytics. These are useful reminders of discussion areas. Their presence does not establish that your proposed design handles collisions, expiration races or inconsistent caches.

In the practice view we inspected, we did not observe a code submission, executable test result or independent design verdict. This is a bounded observation about that view, not proof that no other page or future release can provide feedback. The title’s “without a verified judge” describes our evidence boundary.

The resource library also used free and paid labels and recommendation-style descriptions. Those are curation signals from the site, not our independent endorsement of every resource, its current price or its effectiveness. Follow the destination and verify the exact material before planning around it.

A completion label needs an evidence definition

A personal Done state can mean several things: you watched a video, drew a diagram, implemented a small component or defended trade-offs under questioning. None is inherently dishonest, but they are different accomplishments. The interface cannot tell you which one you mean unless you define it.

For a study roadmap, attach a short evidence note to the topic. It might contain the requirement you addressed, one rejected alternative, one failure case and a question you still cannot answer. That note makes a later review possible even when you no longer remember why you clicked Done.

Do not infer assessed readiness from a progress percentage. A counter can accurately summarize your labels while saying nothing about whether the designs meet their contracts. Conversely, an unmarked topic can still be an area where you have substantial project experience. Curriculum state and skill evidence answer different questions.

Our editorial recommendation is to use the site for navigation and use a separate review standard for completion. That standard can be a human mock, a reproducible small model or a written defense of an explicit trade-off. The right evidence depends on the task; not every HLD decision is reducible to an automated unit test.

One URL-shortener prompt, two different design depths

Here is our original study packet, inspired by the practice entry’s topic rather than copied from a vendor reference. A service creates short codes for long URLs and resolves them until expiration. Define the expiration rule as exclusive: a record valid until time 100 resolves at 99 and stops resolving at 100.

For HLD, begin with the service boundary. Which requests create mappings, which resolve them, where is the authoritative record, and how do replicas or caches learn that a record expired? You need enough detail to identify how a user could receive a redirect after the declared deadline.

For LLD, begin with the operation contracts and ownership. A repository owns uniqueness of short codes. A resolver compares the current time with the stored expiry. An injected clock can make the deadline test reproducible. These choices make the behavior testable without claiming you have built the whole distributed service.

The HLD diagram and LLD contracts must preserve the same requirement. An HLD diagram that promises strict expiry and an LLD resolver that serves stale cached records implement incompatible stories. Resolving that mismatch is more valuable than adding another component label.

None of these choices is a verified implementation inside mySystemDesign. They are our exercise for turning a curriculum label into work you can inspect and defend.

A tiny expiration check exposes a real decision

We executed a small local Python oracle with one mapping, code ab, pointing to an example URL and expiring at time 100. The resolver returned the target at 99 and no target at 100 or 101. A duplicate-code check also recognized that ab was already present.

This fixture establishes the declared local boundary, not the behavior of a production datastore or the practice platform. It has no cache, network, replication or clock skew. Its value is that it forces a precise answer to “is the deadline inclusive?” before the architecture becomes more complex.

Now add a cache that stores the target for 60 seconds. If a request at time 99 populates that cache without respecting the record’s expiry, a later request can bypass the correct local resolver. The original unit-sized result still passes, but the composed service can violate the same requirement.

There are several possible policies. Limit cache lifetime to the remaining validity, revalidate on resolution or explicitly allow bounded stale redirects. Which is appropriate depends on the stated product requirement and infrastructure. The practice objective is to make the trade-off visible and consistent across layers.

The same method works for collision handling. A local dictionary can recognize an existing code, but two concurrent creators require an authority that resolves the conflict atomically. “Check first, then insert” leaves a gap if those actions are separate. Your HLD must say where that gap closes, and your LLD must expose a method contract that can represent the conflict.

Turn a resource collection into a selection decision

A resource library can reduce the effort of finding material, but it can also encourage endless reading. Select a destination because it answers a question your current design leaves open. For example, if you cannot explain cache expiry, a guide about that boundary is more useful than a second broad URL-shortener video.

After reading, close the guide and redraw only the part you changed. Write the previous assumption, the new decision and its cost. If the resource did not change or clarify anything, you may have reviewed familiar content rather than closed the preparation gap.

Free and paid labels should be checked at the destination. A free preview may not include the relevant worked exercise, and a paid resource may be unnecessary for the narrow question you need to answer. We did not purchase or endorse the library’s external offerings.

Likewise, popularity-style or star labels should not substitute for your own fit test. A highly regarded general resource can still omit the particular failure you need to understand. Prefer a source that lets you challenge the decision with a concrete case over a page whose main effect is to add terminology to your diagram.

Rehearse changes rather than memorizing one diagram

A useful mock begins with your original packet and changes one requirement. Ask for user-chosen aliases, immediate revocation, regional availability or analytics that must not slow redirects. Identify which previous decisions remain valid and which now need revision.

For user-chosen aliases, collision behavior becomes user-visible rather than merely an internal retry. For immediate revocation, bounded stale caches may no longer satisfy the contract. For analytics, decide whether an unavailable analytics path blocks resolution or loses events under an explicit policy.

Do not respond to every change by adding a queue. A queue changes timing, ordering and failure recovery; it does not automatically preserve uniqueness or expiry. Explain the new source of truth and the acknowledgment boundary before drawing it into the design.

During self-review, distinguish questions you can answer from implementation facts you have observed. “I would use conditional insertion” is a proposed mechanism. “This local test rejected a duplicate” is a bounded observation. “This handles our target traffic” requires evidence we did not collect for this review.

The roadmap can then record meaningful progress: you completed the initial design, found an expiry inconsistency, revised the cache policy and still need to discuss regional failure. That is a more useful state than a single unqualified checkmark.

Five questions for design evidence

These independent PracHub records extend the same domain through security, implementation, debugging and high redirect traffic. They are not assessed mySystemDesign submissions or predictions of a specific employer’s interview.

Use the local implementation prompt if you need method-level evidence. Use the AI-generated shortener debugging task to challenge plausible code rather than start from a blank diagram. The high-traffic design question changes scale assumptions, so the tiny expiration oracle cannot serve as its performance proof.

The HLD section can help organize what to study next, but keep completion evidence attached to the specific requirement. We did not verify a judge, account recovery or a hiring-readiness measurement. Those limits are compatible with using the site effectively as a curriculum.

mySystemDesign is a sensible fit when your immediate problem is selecting and organizing design topics. If your problem is independent feedback on a completed design, arrange that separately and verify the feedback mechanism before relying on it. Take one prompt from PracHub’s Software Engineer questions, write its contract, and bring both the diagram and the counterexample to your next mock.

Sources and further reading

• mySystemDesign roadmap and navigation
• Practice: HLD and LLD entries and progress controls
• Resource library and destination descriptions
• mySystemDesign HLD section