Requirements

Functional Requirements:

1. External production and event service - allows Ticketmaster to sell tickets for specific events. Likely includes "vendor" subservice where vendors can sign up their event or event planning company to Ticketmaster where they can link events
2. User-facing service allowing users to connect to Ticketmaster and create accounts, login, auth, etc. Inlude OAuth options.
3. Payment service to accept user payments for tickets
4. Ticker browsing service that holds all tickets and allows users to search for them (Search service)
5. Reselling service - marketplace-type service where authorized users can sell/purchase second-hand tickets
6. Databases to store tickets, users, vendors
7. Ledger to store money actions and movements
8. AI Agent service (chatbot) that assists users - can query available tickets, and help around the sight. RAG, vector embedding db..
9. Ticket seating requirement: a service that uses vendor partnerships to provide maps where users can click and pick their seats. Seats are cached very quickly in Redis (which is atomic meaning no overlap in requests) and a lock can be established for that ticket while the user is working on their transaction (so we will need a redis service).
10. No double booking.. we can use Redis until the transaction is finished, to store a lock on the user with the specific ticket, so they cannot select it again or book it again during their transaction. After they finish the transaction we add a lock to the relational database (a flag) that the user got this specific ticket.

Non-Functional Requirements:

• Must be high-availability. Because there are many microservices required, we could choose to host it on AWS ECS , or if we have the need or the team, a Kubernetes cluster like EKS with a loadbalancer for user requests and any user interactions, so that we can have horizontal scaling for the various services. Auto-scaling, self-healing, and replication
• Reliability comes with replication and high availability
• Database sizing... every ticket could run around 1-5kb, pretty light, but you can have millions of tickets.. so I would start with 50-100GB of storage (CNPG HA PSQL storage could be good to store tickets).
• As for payments, I would start with 50-100GB as well. You can always scale up or down easily in CNPG.
• We want low-latency, but need secure payment, secure authentication by users. The ideal goal is a p90/95 of 2-3 seconds for heavy tasks like payment confirmations, while selecting seats should be p50, as it's a time-sensitive thing especially when tickets sell out.

List the key non-functional requirements (performance, scalability, reliability, etc.)...

Capacity Estimation

• Assume 500,000 users daily, 10 million total users
• Each ticket is likely 1-5kb (digital ticket). Assuming the simple case of, say, 5 tickets for 5 events per user on average YTD, that's 25 million max kb for tickets, which is around 25 GB. For padding, 50 GB would be a good baseline for a database like PSQL.

API Design

I would go with a mix of REST and gRPC for this, as this is

can involve both actions and classic endpoints.

REST:

• User-facing - user profile, ticket searching section, settings , front-end interaction, web-app interaction
• Payment UI and interaction
• DB querying via web app ORM (object relational mapping)
• Getting vendor information and ticket information

gRPC:

• Payment internal processing due to high speed and lack of need for human readability

High-Level Design

• We have a client accessing the site which triggers their traffic to enter a load balancer, distributing to a series of API gateway instances, which then traffics the client to their desired service, whether it's User service for auth or logging in or their profile, Ticket search service for them to search for tickets and events, or Marketplace service for them to trade or buy/sell secondhand tickets. The ticket search service has access to the payment service, as clients can purchase tickets via the search interface. It also connects of course to a database of all available tickets, with a load balancer to distribute the queries across DB replicas for fast returns.
• The user service connects to a User database to store user information
• The payment service connects to a ledger database to store all transaction logs, and a wallet service that performs the payment execution and connects to the payment service provider.
• Lastly, we have the vendors that work with ticketmaster to provide their tickets that can be purchased. They have their own suite and dedicated load balancer that hits the API gateway instances, reaches the ticket vendor service, which stores available tickets in the database.
• We have a cache for ticket searches for faster searching if they were already searched
• We have a cache that locks tickets from being available to other users. This cache receives information from the purchasing service, and is invoked by the search service to check if the ticket is available and can be returned as a result.

Database Design

• We could use NoSQL for the ticket storage itself, given that they are lightweight and do not require many relations. Each ticket has a unique UUID.
• Relational database like PSQL for the user database, to store user information, and transaction or ticket ownership data (which is why I connected the user database with the payment service. Following a successful payment, mark that user owns that ticket id).
• Relational database for the ledger to track transactions and relationship with users.

Detailed Component Design

• For the Ticket search service, we would implement a searching mechanism by string, that uses fast/efficient searching algorithms. We could benefit from caching ticket searches that were "Recently searched".
• When a user searches for a ticket, if the ticket returns a result and they click the ticket, we must run a check that this ticket is not locked by checking Redis cache locks with that Ticket's UUID. If it's locked the clicking of the ticket cancels and the user gets a message the ticket was already sold. Ideally, when querying tickets, we check if the ticket was sold or not and don't return it or return and display it as sold. That's why I connected the payment service to the ticket databases - we update the ticket by UUID as sold when purchase complete.
• Users can access the ticket purchasing service directly from the ticket search service, by clicking buy for the ticket they like.
• The ticket search service of course connects to a ticket database via loadbalancer distributing load to database replicas, to query for the tickets.

• For the Marketplace service, this is where users can enter a dedicated space that also connects to the ticket search service, which returns tickets that are marked as resellable.
• in this service users can purchase or sell tickets owned by other people. this naturally connects to the payment service to process this. We could go deeper and create another diagram section before the payment service, where marketplace transactions specifically are handled.

• For the ticket databases, I chose to implement replicas given the sheer size of queries that can come for tickets of different kinds. If noSQL like Mongodb makes sense here, as tickets are lightweight and self-defined, without need for heavy relations