2 - Queue Management Service is not implemented

[bchewy]

Queue Management Service is not implemented #12

Detailed Description; Refer to https://github.com/bchewy/bolabola/issues/12#issuecomment-1938779634

[tanhaoen]

Proposed design for the Queue Management Service

Note: the QMS is an optional feature to add for an event, set by the event creator

The Queue Management Service (QMS) is used to regulate traffic going into the seat reservation service especially for events with high traffic (e.g. Coldplay, Taylor Swift). This reduces the number of conflicts (race conditions) that happens in the seat booking process (e.g. two people trying to get the same seat), and ensures a fair booking experience for users.

Ticketboost QMS vs Ticketmaster Smart Queue

My proposed version of the QMS differs slightly from Ticketmaster's implementation (Smart Queue):

Ticketmaster Smart Queue - does not require login, queue number is tagged to the device instead of user account (i.e. a user can queue with multiple devices) Ticketboost QMS - requires the user to be logged in, limit to only one device per user

This reduces the number of clients in queue and would likely be more fair for everyone.

Microservice Design

The QMS consists of two main servers

• Server 1 (S1): Websocket server which will send a message to SQS and keep the connection with the client open
• Server 2 (S2): Centralized Queue Processing server which consumes messages from SQS

Websocket: Web protocol (HTTP, AMQP etc.) that is well suited for real-time, bidirectional communication

JSON Web Token (JWT): An open standard used to share security information between two parties — a client and a server. Each JWT contains encoded JSON objects, including a set of claims. JWTs are signed using a cryptographic algorithm to ensure that the claims cannot be altered after the token is issued

Process Flow

1. Authenticated user (client) establishes a Websocket connection to S1 and sends their user ID in the request body
2. S1 adds a message mapping the user ID to the associated Websocket connection to an AWS SQS (Simple Queue Service) queue (RabbitMQ can also work but wanted to have some variety)
3. S2 continually consumes (dequeues) messages from SQS (consider having some queue processing logic to better manage out the traffic)
4. When a user ID reaches the front of the queue, it is dequeued and S2 creates a JSON Web Token (JWT) and sends it back to the client via Websocket. The JWT authorises the client to enter the seat reservation service.
5. S2 closes the client's Websocket connection

[tanhaoen]

Base code completed with #20

[bchewy]

Reopening for trakcing