Design an Extensible Cinema Ticket Pricing Engine

Read the full interview experience this question came from →

Quick Overview

Design an extensible cinema pricing engine with validated money and multiplier types, composable policies, explicit calculation and rounding, compatibility checks, versioned configuration, itemized quotes, and boundary tests.

Design an Extensible Cinema Ticket Pricing Engine

Company: Amazon

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

## Interview Prompt Design a ticket-pricing engine where a movie format supplies a base price, showtime and seat tier each supply a multiplier, and zero or more add-ons supply fixed prices. The final price is `(base price + add-on total) * showtime multiplier * seat-tier multiplier`. Explain a type-safe, testable design that can add new formats, showtimes, tiers, or services without editing a large conditional. ### Constraints & Assumptions - Represent money with integer minor units or decimal arithmetic, never binary floating point. - Multiplier and rounding policy must be explicit and consistent. - Unknown or incompatible options are rejected rather than silently defaulted. - Pricing configuration is versioned so a quote can later be audited. ### Clarifying Questions to Ask - At which step is rounding applied? - Can an add-on be restricted by format, showtime, or seat tier? - Must previously issued quotes remain reproducible after configuration changes? ### What a Strong Answer Covers - Value objects for money and multipliers with validated invariants. - Composable pricing components or policies instead of format-specific branching. - An explicit calculation order, rounding rule, and itemized quote output. - Configuration/version separation from pricing logic and audit-friendly inputs. - Unit, property, and compatibility tests for combinations and boundary values. ### Follow-up Questions - How would coupons and taxes fit without changing every price component? - How do you prevent a new add-on from being sold with an incompatible seat? - What should an idempotent quote API return when pricing configuration changes mid-request?

Overview: Design an extensible cinema pricing engine with validated money and multiplier types, composable policies, explicit calculation and rounding, compatibility checks, versioned configuration, itemized quotes, and boundary tests.

Read the full Amazon Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Amazon
Amazon logo
Amazon
May 1, 2026
mediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
1
0

Interview Prompt

Design a ticket-pricing engine where a movie format supplies a base price, showtime and seat tier each supply a multiplier, and zero or more add-ons supply fixed prices. The final price is (base price + add-on total) * showtime multiplier * seat-tier multiplier. Explain a type-safe, testable design that can add new formats, showtimes, tiers, or services without editing a large conditional.

Constraints & Assumptions

  • Represent money with integer minor units or decimal arithmetic, never binary floating point.
  • Multiplier and rounding policy must be explicit and consistent.
  • Unknown or incompatible options are rejected rather than silently defaulted.
  • Pricing configuration is versioned so a quote can later be audited.

Clarifying Questions to Ask Guidance

  • At which step is rounding applied?
  • Can an add-on be restricted by format, showtime, or seat tier?
  • Must previously issued quotes remain reproducible after configuration changes?

What a Strong Answer Covers Guidance

  • Value objects for money and multipliers with validated invariants.
  • Composable pricing components or policies instead of format-specific branching.
  • An explicit calculation order, rounding rule, and itemized quote output.
  • Configuration/version separation from pricing logic and audit-friendly inputs.
  • Unit, property, and compatibility tests for combinations and boundary values.

Follow-up Questions Guidance

  • How would coupons and taxes fit without changing every price component?
  • How do you prevent a new add-on from being sold with an incompatible seat?
  • What should an idempotent quote API return when pricing configuration changes mid-request?
Loading comments...