Requirements

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
User-facing service allowing users to connect to Ticketmaster and create accounts, login, auth, etc. Inlude OAuth options.
Payment service to accept user payments for tickets
Ticker browsing service that holds all tickets and allows users to search for them (Search service)
Reselling service - marketplace-type service where authorized users can sell/purchase second-hand tickets
Databases to store tickets, users, vendors
Ledger to store money actions and movements
AI Agent service (chatbot) that assists users - can query available tickets, and help around the sight. RAG, vector embedding db..
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).
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.

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.)...