Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
List non-functional requirements for the system...
CAP
Estimate the scale of the system you are going to design...
Define what APIs are expected from the system...
Public endpoints - /cities/*, /events/*
Authorised endpoints - /bookings/*
List Cities - Get All cities in a country
GET /1/cities/:countryCode
Optional Request Header: [
"Authorization" : Bearer <OAuth token>
]
Response: 200 OK
Response Body: [A list of City instances]
List Events in a City
Optional filters - if missing, API returns all events near the user's area/city
GET /1/events?city={cityCode}&event={eventName}
Request Header: [
"Authorization" : Bearer <OAuth token> // Optional
]
Response: 200 OK
Response Body: [A list of Event instances in a City]
List a particular event and its venues, tickets available at each venue
GET /1/events/:eventId
Request Header: [
"Authorization" : Bearer <OAuth token> // Optional
]
Response: 200 OK
Response Body: [Details of an event]
Venues that an event is running in city
GET /1/events/:eventId/venues
Request Header: [
"Authorization" : Bearer <OAuth token> // Optional
]
Response: 200 OK
Response Body: [List of venues that screens the event]
List seats for an event
GET /1/events/:eventId/venues/:venueId/shows/:showId/seats/
Request Header: [
"Authorization" : Bearer <OAuth token> // Mandatory, user is logged in at this point
]
Response: 200 OK
Response Body: [A list of Seats for the event at the venue]
Book tickets for an event
POST /1/bookings
Request Header: [
"Authorization" : Bearer <OAuth token> // Mandatory, user is logged in at this point
]
Request Body: {An instance of Booking request object, contains showId, venueId, selected seats, payment session id}
Response: 201 OK, 204 Accepted waiting for payment confirmation, 409 conflict, 429 too many requests
Response Body: [An instance of Booking confirmation which includes tickets]
List historical bookings of the user
List all booking of a user, status is missing then all booking entries are returned in reverse chronological order
GET /1/bookings/:userId/status=confirmed|cancelled|pending
Request Header: [
"Authorization" : Bearer <OAuth token> // Mandatory, user is logged in at this point
]
Response: 200 OK
Response Body: [A list of Booking instances, confirmed as well as pending to confirm]
Cancel a Booking
DELETE /1/bookings/:bookingId/
Request Header: [
"Authorization" : Bearer <OAuth token> // Mandatory, user is logged in at this point
]
Request body: {An instance of confirmed booking }
Response: 201 OK
Response Body: [Booking cancellation confirmation ]
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
Core Entities
For keyword searches for venue, events and natural laguage and fulll text queries , the master data of events, venue, city are indexed into a Elasticsearch search engine. The read replica is updated via CDC (Change data capture) and its eventual consistency. The booking and seats availability information are pulled from master database.
Elasticsearch schema
Event: {
eventId: ""e01,
version: "1.0",
title: { raw: "The Godfather", keyword: "The Godfather"}
description: "A groundbreaking crime drama that revolutionized the genre"
cast: [name: "Al Pacino", role: "Micheal Corleone"],
duration: 2.55
}
Venue: {
venueId: "v01",
version: "1.0",
title: "PVR MAX",
city: "BLR",
location: {lat: long: },
capacity: 250
facilities: ["3D", "recliner"]
}
RunningEvent: {
runingEventId: "re01",
version: "1.0",
venueTitle: "PVR MAX",
city: "BLR",
location: {lat: 12.23, long: 12.78},
capacity: 250,
shows: [{
name: "Firstshow",
startTime:
}]
}
The datase is for each event id + sectionid + row id, the hash of these keys makes the request spread across different partitions. the seats are located closely under this key making the read/writes to a partition. In a popular event almost all of the partitions are utilized equally. when a user books more than one seat, the max chances are that the user always books in the same row which ends up in the same paritition.
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
General Read Flow - non-authenitcated endpoints
Endpoints "/cities/*", "/events/*", "/search/*"
client > NLB - L4 > Regional ALB - L7 (Terminate SSL) > API Gateway (logging, metrics, Authz) > Listing Microservice > Cache > Elasticsearch (On cache miss)
Booking Flow
client > NLB - L4 > Regional ALB - L7 > API Gateway > Booking Service > Block seats in Redis cache with TTL 5 mins > Initiate Payment Oder > Payment Gateway {async callback with webhook } > redirect user to payment gateway page > {on fail or success, payment gateway calls webhook} > {on success : book and block seats in database} > {on fail: release locked seats } > redirect user to seat selection with latest seat availability
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?