Clarify scope and actors - Low-Level Design Guide

Overview

Step 1 of every LLD interview: turn a one-line prompt into a clear scope. Ask who the actors are (customer, admin, attendant, system jobs), what core use cases must work, what is explicitly out of scope, and which non-functional qualities matter (concurrency, extensibility, persistence, API vs in-memory). Then write the agreed list where the interviewer can see it.

Good clarification is fast (about 5 minutes), structured, and ends with stated assumptions. It prevents designing the wrong system, shows product sense, and gives you a checklist to validate against at the end. This workflow series uses one running example: 'Design a movie ticket booking system'.

An architect's first client meeting

Before drawing anything, the architect asks: how many people live here, what rooms do you need, what budget, any future extension? Designing a mansion when the client wanted a studio is a failure no matter how good the drawings are.

When to use it

The first minutes of any LLD or machine-coding round.
Whenever a requirement is ambiguous mid-design.
Before choosing patterns or data structures.

Where it shows up in interviews

Open-ended prompt

Recognize it when: 'Design X' with no details.

Design a movie ticket system
Design a parking lot
Design an elevator system

Where it is used in real software

Product discovery

Engineers and PMs write goals, non-goals, and personas before technical design.

Design docs

Google and Amazon design docs start with context, goals, and non-goals sections.

Interview rubrics

LLD rubrics commonly score requirement gathering as a separate dimension.

Key terms

Actor: A user role or system that interacts with the design.
Core use case: Must-have flow for the interview.
Non-goal: Explicitly excluded to save time.
Assumption: A reasonable default you state out loud.

How it works, step by step

1
Restate the goal
'Users book seats for movie shows in cinemas.'
2
List actors
Customer, cinema admin, payment system, scheduler.
3
Prioritize use cases
Search shows, view seats, book with hold, pay, cancel.
4
Ask about constraints
Concurrent bookings? Hold time? Seat types? Refund policy?
5
State scope and assumptions
In-memory, single city first, card payment via gateway interface.

Clarified scope for the movie ticket system

Five minutes of questions

Category	Decision
Actors	Customer, Admin, PaymentGateway (external)
In scope	Browse shows, view seat map, hold seats (10 min), pay, confirm, cancel
Out of scope	Reviews, recommendations, food orders, loyalty
Non-functional	No double booking under concurrency; pricing rules extensible
Assumptions	In-memory storage, one currency, seats priced by type

NOWCategory: Actors | Decision: Customer, Admin, PaymentGateway (external)

This table is the contract for the next 40 minutes.

Implementation

1// Capture agreed scope as the top-level API you will implement2export interface BookingSystem {3  // Customer4  searchShows(city: string, movie?: string, date?: string): Show[];5  seatMap(showId: string): SeatView[];6  holdSeats(userId: string, showId: string, seatIds: string[]): Hold;       // expires in 10 min7  confirm(holdId: string, paymentToken: string): Promise<Booking>;8  cancel(bookingId: string, userId: string): Refund;9  // Admin10  addShow(cinemaId: string, screenId: string, movieId: string, startsAt: Date): Show;11}12// Out of scope (mentioned, not built): reviews, food, loyalty points

Complexity and performance

Time budget~5 of 45 minutes

Worth it.

Use cases3-6 core

Depth over breadth.

Trade-offs

Asking vs assuming

Ask about decisions that change the design (concurrency, persistence); assume minor details and say so.

Breadth vs depth

A smaller scope designed well beats a large scope designed shallowly.

Variants and related techniques

Machine-coding rounds

Scope is often fixed; clarify input format, commands, and expected output.

Design discussions

Scope can expand; revisit priorities explicitly.

Common mistakes

Starting to code immediately.
Fix: Spend a few minutes clarifying.
Asking questions without concluding.
Fix: Summarize decisions and assumptions in writing.
Ignoring non-functional needs.
Fix: Ask about concurrency and extensibility explicitly.

Interview questions

What would you clarify for 'Design a parking lot'?

Vehicle types and spot sizes, floors and entrances, ticketing and payment, pricing model, concurrency at multiple gates, display boards, and what is out of scope (reservations, cameras).

How long should clarification take?

About five minutes in a 45-minute round, ending with a written list of use cases, out-of-scope items, and assumptions.

Practice problems

Problem	Difficulty	What it trains
Clarify 'Design a food delivery app' in 5 minutes	Easy	Actors and scope.
Clarify 'Design a hotel booking system'	Medium	Constraints.