HLD vs LLD: What Is the Difference & How Each Interview Is Evaluated

Indian product-company interview loops increasingly contain two different "design" rounds, and candidates regularly prepare for the wrong one. Someone walks into a Flipkart-style machine coding round ready to talk about Kafka and sharding, or into a senior HLD round and starts writing a Seat class. This post draws the line precisely, then solves one problem, a BookMyShow-style seat booking system, at both levels so you can see exactly how the deliverables differ.

The One-Line Difference

HLD asks "what are the pieces and how do they talk at scale?" LLD asks "how is one piece written so it is correct and easy to change?"

Think of designing a city vs designing a building. The city plan (HLD) decides where the highways, power plants, water supply and districts go and how they handle a million residents. The building blueprint (LLD) decides rooms, wiring and plumbing for one building, in enough detail that a contractor can build it. Both are "design", but the vocabulary, artifacts and judgement criteria are different.

HLD vs LLD Side by Side

The Same Problem as HLD: BookMyShow at Scale

Prompt: "Design a movie ticket booking system like BookMyShow." Here is a compressed version of what a strong 45-minute HLD answer covers. The full design is in Design BookMyShow.

1. Requirements

• Functional: browse movies by city, view shows and seat map, hold seats for a few minutes, pay, get a ticket.
• Non-functional: no double booking (strong consistency on seats), seat map loads fast, handles a blockbuster opening-day spike, payment failures release seats.

2. Estimates

• Assume 10M DAU browsing, 1M bookings/day → ~12 bookings/s average, but a popular release opening bookings can create thousands of seat-hold attempts per second on a handful of shows.
• The read path (catalog, show listings) is 100× the write path; the hard part is contention on a few hot shows, not raw volume.

3. Architecture

4. Deep dives an interviewer expects

• Preventing double booking: hold seats with an atomic Redis SET seat:{show}:{seat} {user} NX EX 600 for all seats in one Lua script, and enforce correctness with a database unique constraint on (show_id, seat_id) for confirmed bookings. The cache is the fast path; the database is the source of truth.
• Hold expiry and payment races: a payment that completes after the hold expired must be refunded or re-validated, never silently double-sold.
• Hot show spike: virtual waiting room, rate limiting per user, shard seat state by show ID.
• Idempotent payment callbacks, reconciliation jobs.

Notice what is absent: no class names, no method signatures, no patterns. Everything is about components, data, consistency and scale.

The Same Problem as LLD: The Booking Module in Code

Prompt: "Design the low-level classes for BookMyShow's booking flow. Multiple users may try to book the same seats concurrently. Seat pricing differs by category." A strong LLD answer starts with entities and behaviour, then code.

1. Entities and relationships

• Movie, Theatre has many Screen, Screen has many Seat (with SeatCategory).
• Show = movie + screen + start time.
• Booking has user, show, seats, amount and a BookingStatus state machine: PENDING → CONFIRMED or PENDING → EXPIRED/CANCELLED.
• SeatLockProvider interface: in-memory implementation now, Redis implementation later.
• PricingStrategy interface: category-based now, dynamic/weekend pricing later (Strategy pattern).

2. Code (Java)

import java.time.Duration;
import java.time.Instant;
import java.util.*;
import java.util.concurrent.ConcurrentHashMap;

enum SeatCategory { SILVER, GOLD, RECLINER }
enum BookingStatus { PENDING, CONFIRMED, EXPIRED, CANCELLED }

record Seat(String id, SeatCategory category) {}
record Show(String id, String movieId, String screenId, Instant startsAt, List<Seat> seats) {}

interface PricingStrategy {
    long pricePaise(Show show, Seat seat);
}

final class CategoryPricing implements PricingStrategy {
    private final Map<SeatCategory, Long> prices;
    CategoryPricing(Map<SeatCategory, Long> prices) { this.prices = prices; }
    public long pricePaise(Show show, Seat seat) { return prices.get(seat.category()); }
}

interface SeatLockProvider {
    boolean lockAll(String showId, List<String> seatIds, String userId);   // all or nothing
    void unlockAll(String showId, List<String> seatIds, String userId);
    boolean isLockedBy(String showId, String seatId, String userId);
}

final class InMemorySeatLockProvider implements SeatLockProvider {
    private record Lock(String userId, Instant expiresAt) {}
    private final Map<String, Map<String, Lock>> locks = new ConcurrentHashMap<>();
    private final Duration ttl;
    InMemorySeatLockProvider(Duration ttl) { this.ttl = ttl; }

    public boolean lockAll(String showId, List<String> seatIds, String userId) {
        Map<String, Lock> showLocks = locks.computeIfAbsent(showId, k -> new HashMap<>());
        synchronized (showLocks) {                       // per-show lock: shows don't block each other
            Instant now = Instant.now();
            for (String s : seatIds) {
                Lock l = showLocks.get(s);
                if (l != null && l.expiresAt().isAfter(now) && !l.userId().equals(userId)) return false;
            }
            for (String s : seatIds) showLocks.put(s, new Lock(userId, now.plus(ttl)));
            return true;
        }
    }

    public void unlockAll(String showId, List<String> seatIds, String userId) {
        Map<String, Lock> showLocks = locks.get(showId);
        if (showLocks == null) return;
        synchronized (showLocks) {
            for (String s : seatIds) {
                Lock l = showLocks.get(s);
                if (l != null && l.userId().equals(userId)) showLocks.remove(s);
            }
        }
    }

    public boolean isLockedBy(String showId, String seatId, String userId) {
        Map<String, Lock> showLocks = locks.get(showId);
        if (showLocks == null) return false;
        synchronized (showLocks) {
            Lock l = showLocks.get(seatId);
            return l != null && l.userId().equals(userId) && l.expiresAt().isAfter(Instant.now());
        }
    }
}

final class Booking {
    final String id; final String userId; final Show show; final List<Seat> seats; final long amountPaise;
    private BookingStatus status = BookingStatus.PENDING;
    Booking(String id, String userId, Show show, List<Seat> seats, long amountPaise) {
        this.id = id; this.userId = userId; this.show = show; this.seats = seats; this.amountPaise = amountPaise;
    }
    synchronized BookingStatus status() { return status; }
    synchronized void transition(BookingStatus next) {
        boolean ok = status == BookingStatus.PENDING && next != BookingStatus.PENDING;
        if (!ok) throw new IllegalStateException(status + " -> " + next);
        status = next;
    }
}

final class BookingService {
    private final SeatLockProvider locks;
    private final PricingStrategy pricing;
    private final Map<String, Set<String>> confirmedSeats = new ConcurrentHashMap<>(); // showId -> seatIds
    private final Map<String, Booking> bookings = new ConcurrentHashMap<>();

    BookingService(SeatLockProvider locks, PricingStrategy pricing) {
        this.locks = locks; this.pricing = pricing;
    }

    Booking hold(String userId, Show show, List<String> seatIds) {
        Set<String> taken = confirmedSeats.computeIfAbsent(show.id(), k -> ConcurrentHashMap.newKeySet());
        for (String s : seatIds) if (taken.contains(s)) throw new IllegalStateException("seat taken: " + s);
        if (!locks.lockAll(show.id(), seatIds, userId)) throw new IllegalStateException("seats held by someone else");

        List<Seat> seats = show.seats().stream().filter(s -> seatIds.contains(s.id())).toList();
        long amount = seats.stream().mapToLong(s -> pricing.pricePaise(show, s)).sum();
        Booking b = new Booking(UUID.randomUUID().toString(), userId, show, seats, amount);
        bookings.put(b.id, b);
        return b;
    }

    void confirm(String bookingId) {                      // called after payment succeeds
        Booking b = bookings.get(bookingId);
        Set<String> taken = confirmedSeats.get(b.show.id());
        synchronized (taken) {
            for (Seat s : b.seats) {
                if (!locks.isLockedBy(b.show.id(), s.id(), b.userId)) {
                    b.transition(BookingStatus.EXPIRED);     // hold lapsed: refund path
                    return;
                }
            }
            b.seats.forEach(s -> taken.add(s.id()));
            b.transition(BookingStatus.CONFIRMED);
        }
        locks.unlockAll(b.show.id(), b.seats.stream().map(Seat::id).toList(), b.userId);
    }
}

3. What the LLD interviewer probes next

• "Why an interface for SeatLockProvider?" (Dependency inversion: swap in Redis for multi-instance deployment without touching BookingService.)
• "Add weekend surge pricing." (New PricingStrategy, or a decorator over the base strategy; open/closed principle.)
• "Two users click the same seat at the same millisecond." (Walk through the per-show synchronized block; all-or-nothing locking.)
• "Why not one global lock?" (It serializes every show in the country; per-show locks keep contention local.)
• "Notify the user on confirmation." (Observer or an event publisher interface.)

Compare the two answers: the HLD solved double booking with Redis SET NX plus a database unique constraint across many servers; the LLD solved it with an interface, a per-show lock and a state machine inside one process. Same requirement, different altitude. Patterns used here are covered in Top 10 Design Patterns for Interviews.

LLD Discussion vs Machine Coding Round

In machine coding, a working, well-structured 70% solution beats a beautiful but non-running 100% design. Get the core flow running first, then add features. Worked problems: Parking Lot, Splitwise, Snake and Ladder.

How Each Round Is Evaluated

Rubrics differ by company, but the dimensions below reflect what interviewers commonly write in feedback.

HLD rubric

LLD / machine coding rubric

Which Companies Ask HLD, LLD or Machine Coding?

This is based on commonly reported candidate experiences and changes often; teams within the same company differ, so treat it as orientation and confirm the loop with your recruiter.

Company-specific breakdowns are in LLD Interview Preparation India and System Design Interview Preparation India 2026.

What to Expect by Experience Level

How to Prepare for Both Rounds

For LLD and machine coding

1. Master OOP mechanics in one language: interfaces vs abstract classes, enums with behaviour, immutability, collections, basic concurrency (locks, concurrent maps, atomic types).
2. Learn 8 to 10 patterns by the problem they solve: Strategy, State, Factory, Observer, Builder, Decorator, Singleton, Chain of Responsibility, Command.
3. Solve 12 to 15 classic problems under a timer, actually running the code: parking lot, elevator, Splitwise, snake and ladder, vending machine, library, chess, LRU cache, rate limiter, cab booking, ATM, in-memory KV store with transactions.
4. Use a fixed project skeleton: models, services, strategies, exceptions, a Main driver. Saves 10 minutes every round.
5. Practice the extension: after each problem, add one new requirement and see how much code changes.

For HLD

1. Learn the building blocks: load balancers, caching, databases and sharding, queues, CDNs, consistency models.
2. Use a fixed answer framework: requirements → estimates → API → data model → architecture → deep dives → trade-offs.
3. Do 15 to 20 classic designs out loud, timed: URL shortener, chat, news feed, rate limiter, notification system, ride-hailing, ticket booking, payment system, video streaming.
4. Read real engineering blogs to see how actual systems made trade-offs.

If you are starting from zero on HLD, follow System Design for Beginners: A Step-by-Step Roadmap.

Mistakes Candidates Make in Each Round

In HLD rounds

• Writing classes and method bodies instead of components and data flow.
• Drawing 15 boxes without explaining what flows between them.
• Never discussing consistency for the one place it matters (seats, payments, inventory).
• Not driving the conversation: waiting for the interviewer to ask every question.

In LLD and machine coding rounds

• Talking about microservices, Kafka and sharding when asked for class design.
• Over-engineering: six patterns and twenty interfaces for a 90-minute problem, then running out of time with nothing working.
• Under-engineering: one class with if/else chains on type strings.
• Ignoring concurrency when the problem clearly has shared mutable state (bookings, inventory, elevators).
• Not running the code before time is up.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.