The Question That Actually Matters: What Kind of Seat

You've mapped BookMyShow's physical structure into a sequence of requirement questions: city, then movies in that city, then theatres and showtimes for a chosen movie. One judgment call is still left — deciding which "can there be more than one" question is actually worth asking out loud, and which one just wastes the interviewer's time.

Skip Questions That Don't Change the Design

Three examples from this walkthrough show which is which:

1. City to theatre — skip it. "Can one city have multiple theatres?" is as obvious as asking whether a classroom can hold more than one student. It teaches the interviewer nothing new.
2. Auditorium to seats — skip it. Of course an auditorium holds many seats. There's no design consequence hiding in that question.
3. Theatre to auditorium — ask it. "Can a theatre have multiple auditoriums?" looks like the same kind of question, but the answer changes something concrete: if a theatre can screen several movies at once, a ticket has to identify which auditorium a seat is in, not just which theatre.

The question is worth asking when the answer changes what you have to store, not just whether a list might hold more than one item. A list works fine even if it only holds one item, so design assuming a list from the start, and raise the question only when a "yes" would force you to change the data itself.

The Real Question About Seats

At the seat level, the obvious question ("can an auditorium have multiple seats?") isn't useful — of course it can. The useful question is what kind of seat you're looking at.

A single auditorium usually sells more than one tier of seat: Silver, Gold, Platinum, and sometimes Balcony or box. That list itself isn't the design question. The design question is whether it's fixed for the whole platform, or whether individual theatres can invent their own tier names, and the answer decides how SeatType gets modeled:

1. Tiers are fixed platform-wide — SeatType is an enum. Every theatre picks from the same set of names, so the valid values are known in advance.
2. Theatres can name their own tiers — SeatType is a class. The set of valid values can no longer be hardcoded, so SeatType needs its own class with at least a name field.

For a real platform like BookMyShow, individual theatre chains do name their own tiers, so the answer points to a class.

Pricing Is a Relationship, Not a Property

The narrow version of the pricing question is "does price depend on seat type?" That's fine, but it invites a narrow answer. The better version asks for the full list of factors right away: what actually determines the price of a single seat?

Walk through it and three factors show up:

1. The seat type. A Gold seat costs more than a Silver one.
2. The theatre. The same movie at a premium multiplex costs more than at a smaller one.
3. The time of the show. A 6 AM show for a movie nobody wants to watch is priced low, to fill empty seats. But a popular evening slot isn't automatically expensive either — the price still depends on the movie.

That third factor rules out one shortcut: hardcoding a price multiplier by time of day. Pricing has to be something a theatre sets per show, not a formula the system computes on its own, because the same time slot can be cheap for one movie and full price for another.

Why a Seat Type Can't Be a Plain String

That price can't live on "Gold" in general. Gold costs something different at a different theatre, and something different again for a different show at the same theatre. The price is an attribute of the relationship between a seat type and something else, not an attribute of the seat type by itself.

ExpandPrice sits on the relationship between SeatType and Show, not on either entity alone

A plain string can't hold that relationship. It has no identity of its own to attach a price to, so there'd be nowhere to store "Gold costs 250 for this specific show" without duplicating the string everywhere that price applies.

A real class gives SeatType an identity that a price mapping can point to. Deciding exactly what sits on the other side of that mapping matters more than it seems at first.