Build a Virtual Waiting Room with Amazon DynamoDB and AWS Lambda at SeatGeek
AWS Architecture BlogBuild a Virtual Waiting Room with Amazon DynamoDB and AWS Lambda at SeatGeekby Umesh Kalaspurkar, Ander Parra, Cici Xue, and Ilya Marmur | on29 JUL 2021| inAmazon DynamoDB,Amazon Timestream,Architecture,AWS Lambda,Intermediate (200),Retail|Permalink|ShareAs retail sales, products, and customers continue to expand online, we’ve seen a trend towards releasing products in limited quantities to larger audiences. Demand of these products can be high, due to limited production capacity, venue capacity limits, or product exclusivity. Providers can then experience spikes in transaction volume, especially when multiple event sales occur simultaneously. This increased traffic and load can negatively impact customer experience and infrastructure.To enhance the customer experience when releasing tickets to high demand events,SeatGeekhas introduced a prioritization and queueing mechanism based on event type, venue, and customer type. For example, Dallas Cowboys’ tickets could have a different priority depending on seat type, or whether it’s a suite or a general admission ticket.SeatGeek previously used a third-party waiting room solution, but it presented a number of shortcomings:Lack of configuration and customization capabilitiesMore manual process that resulted in limiting the number of concurrent events could be set upInability to capture custom insights and metrics (for example, how long was the customer waiting in the queue before they dropped?)Resolving these issues is crucial to improve the customer experience and audience engagement. SeatGeek decided to build a custom solution on AWS, in order to create a more robust system and address these third-party issues.Virtual Waiting Room overviewOur solution redirects overflow customers waiting to complete their purchase to a separate queue. Personalized content is presented to improve the waiting experience. Public services such as school or voting registration can use this solution for limited spots or time slot management.Figure 1. User path through a Virtual Waiting RoomDuring a sale event, all customers begin their purchase journey in the Virtual Waiting Room (see Figure 1). When the sale starts, they will be moved from the Virtual Waiting Room to the ticket selection page. This is referred to as theProtected Zone. Here is where the customer will complete their purchase. The Protected Zone is a group of customized pages that guide the user through the purchasing process.When the virtual waiting room is enabled, it can operate in three modes:Waiting Roommode,Queueingmode, or a combination of the two.In Waiting Room mode, any request made to an event ticketing page before the designated start time of sale is routed to a separate screen. This displays the on-sale information and other marketing materials. At the desired time, users are then routed to the event page at a predefined throughput rate. Figure 2 shows a screenshot of the Waiting Room mode:Figure 2. Waiting Room modeIn Queueing mode, the event can be configured to allow a preset number of concurrent users to access the Protected Zone. Those beyond that preconfigured number wait in a First-In-First-Out (FIFO) queue. Exempt users, such as the event coordinator, can bypass the queue for management and operational visibility.Figure 3. Queueing mode flowFigure 4. Queueing modeIn some cases, the two modes can work together sequentially. This can occur when the Waiting Room mode is used before a sale starts and the Queueing mode takes over to control flow.Once the customers move to the front of the queue, they are next in line for the Protected Zone. A ticket selection page, shown in Figure 5, must beprotectedfrom an overflow of customers, which could result in overselling.Figure 5. Ticket selection pageVirtual Waiting Room implementationIn the following diagram, you can see the AWS services and flow that SeatGeek implemented for the Virtual Waiting Room solution. When a SeatGeek customer requests a protected resource like a concert ticket, a gate keeper application scans to see if the resource has an active waiting room. It also confirms if the configuration rules are satisfied in order to grant the customer access. If the customer isn’t allowed access to the protected resource for whatever reason, then that customer is redirected to the Virtual Waiting Room.Figure 6. Architecture overviewSeatGeek built this initial iteration of the gate keeper service onFastly’sComputer@Edge service to leverage its existing content delivery network (CDN) investment. However, similar functionality could be built usingAmazon CloudFrontandAWS Lambda@Edge.TheBouncer, handling the user flow into either the protected zone or the waiting room, consists of 3 components –Amazon API Gateway,AWS Lambda, and a Token Service. The token service is at the heart of the Waiting Room’s core logic. Before a concert event sale goes live at SeatGeek, the number of access tokens generated is equivalent to the number of available tickets. The order of assigning access tokens to customers in the waiting room can be based on FIFO or customer status (VIP customers first). Tokens are allocated when the customer is admitted to the waiting room and expire when tickets are purchased or when the customer exits.For data storage, SeatGeek usesAmazon DynamoDBto monitor protected resources, tokens, and queues. The key tables are:Protected Zone table:This table contains metadata about available protected zonesCounters table:Monitors the number of access tokens issued per minute for a specific protected zoneUser Connection table:Every time a customer connects to the Amazon API Gateway, a record is created in this table recording their visitor token and connection ID using AWS LambdaQueue table:This is the main table where thevisitor tokentoaccess tokenmapping is savedFor analytics, two types of metrics are captured to ensure operational integrity:System metrics:These are built into the AWS runtime infrastructure, and are stored inAmazon CloudWatch. These metrics provide telemetry of each component of the solution: Lambda latency, DynamoDB throttle (read and write), API Gateway connections, and more.Business metrics:These are used to understand previous user behavior to improve infrastructure provisioning and user experiences. SeatGeek uses an AWS Lambda function to capture metrics from data in a DynamoDB stream. It then forwards it toAmazon Timestreamfor time-based analytics processing. Metrics captured include queue length, waiting time per queue, number of users in the protected zone, and more.For historical needs, long-lived data can be streamed to tiered data storage options such asAmazon Simple Storage Service (S3). They can then be used later for other purposes, such as auditing and data analysis.Considerations and enhancements for the Virtual Waiting RoomTokens:We recommend using first-party cookies and token confirmations to track the number of sessions. Use the same token at the same time to stop users from checking out multiple times and cutting in line.DDoS protection:Token and first-party cookies usage must also comply with General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) guidelines depending on the geographic region. This system is susceptible to DDoS attacks, XSS attacks, and others, like any web-based solution. But these threats can be mitigated by usingAWS Shield, a DDoS protection service, andAWS WAF – Web Application Firewall. For more information on DDoS protection, read thissecurity blog post.Marketing:Opportunities to educate the customer about the venue or product(s) while they wait in the Virtual Waiting Room (for example, parking or food options).Alerts:Customers can be alerted via SMS or voice when their turn is up by usingAmazon Pinpointas a marketing communication service.ConclusionWe have shown how to set up a Virtual Waiting Room for your customers. This can be used to improve the customer experience while they wait to complete their registration or purchase through your website. The solution takes advantage of several AWS services like AWS Lambda, Amazon DynamoDB, and Amazon Timestream.While this references a retail use case, the waiting room concept can be used whenever throttling access to a specific resource is required. It can be useful during an infrastructure or application outage. You can use it during a load spike, while more resources (EC2 instances) are being launched. To block access to an unreleased feature or product, temporarily place all users in the waiting room and let them in as needed per your own configuration.Providing a friendly, streamlined, and responsive user experience, even during peak load times, is a valuable way to keep existing customers and gain new ones.Be mindful that there are costs associated with running these services. To be cost-efficient, see the following pages for details:AWS Lambda,Amazon S3,Amazon DynamoDB,Amazon Timestream.Umesh KalaspurkarUmesh is a Sr Solutions Architect at AWS, and brings more than 20 years of experience in design and delivery of Digital Innovation and Transformation projects, across enterprises and startups. He is motivated by helping customers identify and overcome challenges. Outside of work, Umesh enjoys being a father, skiing, and traveling.Ander ParraAnder Parra is Senior Software Engineer at SeatGeek, and has over 10 years of industry experience in software engineering. He has worked with many different types of systems with diverse sets of constraints and challenges, mainly based on JVM (Java and Scala). He is also experienced in high-scale distributed systems and functional programming. Outside of work, Ander enjoys being a father, coffee, and traveling.Cici XueCici Xue is a Solutions Architect with Amazon Web Services (AWS) focused on helping customers build highly scalable and reliable cloud architectures, which address their business needs. Prior to joining AWS, Cici worked as an Architect in the Financial Service Industry specializing in Data Modeling, Migrations, and Microservices architecture.Ilya MarmurIlya Marmur is an Enterprise Solutions Architect at AWS focused on large-scale migrations, data lake architecture, and serverless application design. Prior to joining AWS, Ilya spent over 15 years in the retail sector specializing in integrations, business intelligence applications, ad-tech, and application development.
As retail sales, products, and customers continue to expand online, we’ve seen a trend towards releasing products in limited quantities to larger audiences. Demand of these products can be high, due to limited production capacity, venue capacity limits, or product exclusivity. Providers can then experience spikes in transaction volume, especially when multiple event sales occur […]
Umesh Kalaspurkar
Amazon DynamoDB Amazon Timestream Architecture AWS Lambda Intermediate (200) Retail