Before You Start: LLD Terms and How to Read This Series
The handful of ideas and words this whole series assumes you already know: class, entity, relationship, cardinality, ORM, DTO. Explained once in plain language before the BookMyShow case study uses them.
This series teaches low-level design (LLD) through one worked example: BookMyShow, a movie ticket booking platform. It assumes you can already write code. It does not assume you've ever designed a system before.
This page exists to close that gap. Read it once, before starting the series. Come back to it any time a word shows up later and doesn't immediately click.
What "Low-Level Design" Actually Means
Writing code usually starts with a problem already broken into pieces: a function to write, a bug to fix. Low-level design is the step before that. It's deciding what the pieces even are.
For a system like BookMyShow, that means answering a few questions first. What are the things this system is built from: a Movie, a Theatre, a Seat? What does each thing need to know about itself? How do they connect to each other?
Answer those well, and the actual coding gets much easier, because you already know what to build. That's the whole skill this series teaches: turning a vague product idea into a concrete set of classes and relationships, before writing a line of implementation code.
The Words This Series Uses Constantly
Class
A blueprint for a "thing" your system deals with: Movie, Theatre, Seat. It describes what every movie or theatre has (a title, a name) and what it can do.
Entity
A class that needs its own row in a database, because there are many of them and the system has to tell them apart. Movie is an entity: the system stores thousands of different movies, each with its own title and rating.
A BookMyShow class would not be an entity, even though it sounds like a natural class to have. There's only ever one of it. It's not a thing the system stores many of, it's just the whole system.
This series uses that exact test throughout: will there ever be more than one of this? It's the fastest way to tell a real entity apart from something that only looks like one.
Object
One actual instance of a class. Not "Movie" the blueprint, but this specific movie, "Inception," sitting in memory or in a database row.
Attribute
One piece of data a class holds. A Movie has a title attribute. A Seat has a row and a column.
Relationship (Association)
A connection between two classes. A Theatre has multiple Auditoriums. A Booking belongs to a Show. Most of low-level design is deciding which classes need a relationship to which other classes, and exactly what shape that relationship takes.
Cardinality
How many of one thing connect to how many of another. A Theatre can have many Auditoriums, but each Auditorium belongs to exactly one Theatre. That's a "one-to-many" relationship.
This series works out cardinality for every relationship in the design, because getting it wrong means the database schema can't represent reality correctly.
Enum
Short for enumeration. A fixed, hardcoded list of valid values, like MOVIE or EVENT, or SILVER, GOLD, PLATINUM. Use an enum when the full list of options is known in advance and controlled by you, not by users of the system.
Inheritance
When one class is a more specific version of another. A BallPen and a GelPen might both inherit from a general Pen class, sharing its attributes and adding their own.
Association Class (Mapping Class)
A class that exists only to represent the relationship between two other classes, usually because that relationship itself has its own data. ShowSeat is one: it represents "this specific seat, in this specific show," and it's where a seat's price for that show actually lives.
ORM (Object-Relational Mapper)
A library that automatically converts your classes into database tables, and rows in those tables back into objects, so you don't have to hand-write that translation yourself. This series explains what an ORM actually automates, and where it still needs your input (like cardinality, which it can't guess on its own).
Transaction
A group of database reads and writes treated as one unit: either all of it succeeds, or none of it does. Two transactions running at the same time can try to touch the same data, which is exactly the kind of clash a database's isolation level controls.
Isolation Level (SERIALIZABLE)
A setting that controls how much one transaction can be affected by another one running at the same time. SERIALIZABLE is the strictest level most relational databases offer: if two transactions try to touch the same row at once, only one gets through, and the other waits (or fails, if it waits too long).
DTO (Data Transfer Object)
A small, separate class used only to move data in or out of your system through an API. Not the same as your actual class. A BookTicketRequestDTO might carry only a show ID and a list of seat IDs, even though the real Booking class ends up with far more fields than that.
Controller
Receives an incoming request and does light, immediate checks (is this data even shaped correctly?). It doesn't make business decisions, and it never talks to the database directly.
Service
Holds the actual business logic, the real rules about how booking a ticket works. It's called by a controller, and it doesn't know or care whether the request came from a website, an app, or a script.
Repository
The only piece of code allowed to actually talk to the database. Services ask a repository for data. They never query the database directly.
Dependency Injection
A pattern where a class receives the other objects it needs (its "dependencies") from the outside, instead of creating them itself. A BookingService that needs a SeatRepository gets handed one when it's created, rather than constructing one internally. That makes the code far easier to test and reconfigure.
The One Technique Worth Remembering Above All Others
Almost every hard question in this series gets answered by the same move: look at the real, physical version of the thing you're designing, before thinking about code at all.
Post 2 uses this to find BookMyShow's entities. A real city really does contain real theatres, which really do contain real auditoriums. The technique isn't specific to BookMyShow. It's a general LLD move, worth reaching for on any system: parking lots, ride-sharing apps, food delivery, anything.
Whenever a post in this series says "picture the real version of this," that's this same technique showing up again.
How the Rest of This Series Is Framed
Most posts are written as if you're answering an interviewer's questions. That's the fastest way to force a design decision into the open, since an interviewer won't let a vague answer slide.
But the actual skill being taught is designing the system well. The interview framing is a forcing function for that skill, not a separate thing to learn on top of it. If you're reading this to get better at design generally, not for an interview, everything still applies. Just swap "the interviewer asks" for "you should ask yourself."
Start with The Sentence That Has to Come Before Any Requirement whenever you're ready.
Keep reading