Amazon System Design Experience

Amazon System Design Interview Experience:

Designing an Event Management System Recently, during an Amazon System Design interview, I was asked to design an Event Management System where users can search for events, view details, and book tickets. Here's how I approached the problem.

1. Understanding Requirements

Functional Requirements:

• Search events by location, category, date, and popularity.
• View event details and ticket availability.
• Book and cancel tickets.
• Allow organizers to create and manage events.

Non-Functional Requirements:

• High availability and low latency for event discovery.
• Strong consistency for ticket booking.
• Scalability during high-demand events.
• Prevent double booking and overselling.

1. Understanding the Read/Write Pattern One important discussion was around the read/write ratio. Users might search and explore hundreds of events, but only a small percentage will actually book tickets. For example:

• 1M event discovery requests.
• 100K event detail views.
• 10K booking attempts. This makes the system predominantly read‑heavy. So, instead of treating both workloads equally, I decided to optimize them separately.

1. Important Edge Cases Before designing the architecture, I considered:

• What if 100K users try booking the same event simultaneously?
• How do we prevent double booking of the last available seat?
• What if payment succeeds but booking confirmation fails?
• What if users retry booking due to network timeouts?
• What if a popular event suddenly experiences 100x traffic?
• What happens when a user holds a seat but never completes payment?

1. High-Level Architecture Read Path – Event Discovery

• Elasticsearch for searching, filtering, and sorting events.
• Redis for caching popular events and event details.
• CDN for static content such as event images.
• Event Service for managing event metadata.

Write Path – Ticket Booking

• Booking Service handles booking requests.
• Inventory Service manages ticket availability.
• PostgreSQL handles transactional inventory updates.
• Atomic updates prevent overselling.
• Redis can manage temporary seat holds with expiration.
• Kafka handles asynchronous workflows like notifications.
• Idempotency keys ensure that retries don't result in duplicate bookings.

Key Takeaway The biggest architectural decision came from understanding the workload. Event discovery is read‑heavy and latency‑sensitive, whereas ticket booking is consistency‑critical. Separating these workloads allows us to scale them independently and make better architectural trade‑offs.

#SystemDesign #AmazonInterview #BackendEngineering #DistributedSystems #SoftwareEngineering