Yet Another Virtual Queue Management System Design

7 min readJun 10, 2020

Virtual Queue Management System

This technical whitepaper is an attempt to design an architecturally near perfect virtual queue application.

Background

During the Corona virus pandemic lock down in 2020, Kerala State Beverages Corporation Limited, aka KSBC decided to introduce a virtual queue system, a mobile app to resume the sale of Liquor, Beer and Wine but also same time making sure the state wide lock down protocol is followed, especially social distancing. But due to various reasons the said mobile app became a fiasco (as on 30 May 2020).

As a citizen & netizen, and more over a technology enthusiast, I was following all the news coming out and was closely monitoring the technology aspects or views shared by mainstream and social media, and also the comments posted by the readers. There were logical as well as illogical comments from both the app developers as well as readers. This triggered me to think why an app, which sounds simple, but became a mess for the entire State of Kerala.

Context & Intention

Definitely, political side of the App is not my problem. Intention of this paper is to design a simple, but scalable Virtual Queue system.

Finally, I am making this whitepaper public, under MIT License so the community can refer the design to develop their own applications. And also, contribute suggestions & corrections so we can improve this paper.

Requirements Gathering & Analysis
High Level Solution Design
Deployment Architecture

Requirements

One liner -

“A Virtual Queue Token generator application — which should support Smart Phone and a responsive website.”

More assumptions:

SMS based Virtual Queue Token generator, which is primarily intended for classic mobile (non-smartphone) users, but smartphone users also can use this as an alternate method.
A token validator application for the Bars & outlets
An admin management console, which can- Take Reports, Change token generator Schedule, and CRUD for Bars and outlets
High Level Use Case:

User visits the App
User enters the postal pin code
User gets a eToken with a schedule. The venue is expected to be within 10 KM range
User, as per the time slot given, goes to the allotted venue — Bar or outlet
Bartender, using his mobile app scans the user’s eToken, or enters the eToken received as SMS
Server validates the authenticity of the eToken
User buys the beverage of his choice

Layman’s view:

For a layman, a drunkard will request for a token in the mobile phone and he visits the nearby liquor outlet, shows token on the mobile phone screen which the bartender will be verifying with bartender’s phone and, the liquor of choice will be sold to the customer.

Number of Applications

Based on the initial requirements, we will require:

App for Smart Phones — for Customers
App for Smart Phones — for Outlets
A Website as an alternate way to get token, and also for admin to manage list of outlets & generate reports. Admin module can be avoided if we use tools like Power BI or Tableau by connecting directly to database, or by creating an API
A server side application/or some code to handle SMS based registration & token requests

For Smartphone apps, we can go with cross-platform tools such as Xamarin, Flutter, React Native, or NativeScript. But for scalable applications it is recommended to have them developed as native applications.

Requirements Analysis

Let us think from a Business Analysis/Business Architecture point of view.

Additional problems in Hand:

Token needs to be auto generated and make sure no two customers gets the same token.
Bartender should be able to verify the authenticity of the token so, some information exchange needs to happen. A server will be required.
An inventory should be maintained and various reports need to be generated by admin users
As per policy, the customer should not be able to buy again within N number of days (eg. 4 days)
Customer should be allotted a outlet within 10 kilometers range. So there needs a logic to measure the distance between customer and the outlet.
Needs a database of Bars, Beer & Wine parlors, and any other outlets

Performance benchmark for solution:

It is expected to have max. 2,00,000 simultaneous customers on the first day, and 1,00,000 users after that. (Some sample assumptions)
It is expected to have approx. 10,00,000 customers per day generating the app.

Note: Detailed Requirement gathering and analysis is not much a scope of this paper. Only a basic requirements building activity is done here which is necessary for building the technical solution architecture.

Thus the next level diagram will be like this:

Here is a bird’s eye view pseudo code for the application:

// HelloToken.java    public static void main(String[] args) {        // New Customer wants to buy a bottle
        Customer customer = new Customer();        // STEP 1 - Customer Registration
        customer.RegisterMe("+919999999999", PhoneType.APP ); // App or SMS?        // Assuming Registration successful        // STEP 2 - Customer requests the token using a mobile app, or by sending SMS
        String CustomerToken =  customer.giveMeAToken("695000"); // Pin code        if (CustomerToken != null) {
            //  Assuming Customer gets the token and he goes to the Outlet
            System.out.println("Show this token: " + CustomerToken + " at [this outlet] on [date]");
        } else {
            // Seems there are no slots available, or some other reason Try again later.
            System.out.println("Better luck next time!");            return;
        }        // STEP 3 - At the Outlet, sales guy is scanning the token
        Boolean OutletVerification = new Outlet().isTheTokenShownByCustomerValid(CustomerToken);        if (OutletVerification) {
            // Assuming the validation is success
            System.out.println("Customer says: Wow, I got the bottle!");
        } else {
            System.out.println("Sales guy says: Get lost!");
        }
    }// ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** 
// Behind the screen    public enum PhoneType { APP, SMS };    private static class VQServer {
        // Database
        public String[] tokenDB = { "A", "B","C","D","E" };
        public String[] Outlets = {"Outlet1", "Outlet2", "Outlet3"};        public void registerCustomer(String phoneNumber, PhoneType phonetype) {
            // Register customer        }
        public String requestNewTokenByCustomer(String pinCode) {
            // Logic for - Token generation 
            // Logic for - Find nearest outlet using pinCode            // Send token by SMS if PhoneType is SMS            return "C"; // Sample token
        }        public Boolean validateTokenByOutlet(String token) {
            return Arrays.asList(tokenDB).contains(token); // Validate
        }
    };    static VQServer vqServer = new VQServer();    private static class Customer {        public String giveMeAToken(String pinCode) {
            return vqServer.requestNewTokenByCustomer(pinCode);
        }
        public void RegisterMe(String phoneNumber, PhoneType phonetype) {
            // Customer Registration
            vqServer.registerCustomer(phoneNumber, phonetype);
        }
    }
    private static class Outlet {
        public Boolean isTheTokenShownByCustomerValid(String token) {
            return vqServer.validateTokenByOutlet(token);
        }
    }

Technical Analysis & Solution

We have now in hand the functional requirements. Let us list down few major non-functional requirements.

Scalability — Number of hits matters
Availability — Should work all time
Security — People should not cheat
User friendly — There is no discrimination between Drunkards
Auditability — Any transaction should be transparent
Extensibility — Requirements are Agile today
Fault Tolerance — failures are not acceptable
Performance — Most drunkards are impatient
Quality — No compromise

An enterprise grade solution is what is being showcased here.

High Level generic deployment diagram

Cloud hosting is considered in the solution because of load and cost constraints inconsideration. Same solution can be workable in On-premise as well with minor technical decision changes if the expected load is less.

Remember that there is always another better option for any better option. So whatever technical solution showcased here are just one way to do it. We can customize the design according to the real world scenarios.

Technology Stack

Technology Stack given is just for reference. This project can be done in any stack, such as .NET Core, Java or Python, Azure, AWS, or Google Cloud etc.

Microsoft Azure Solution (Minimal):

Though, this is a minimal design, this is also highly scalable because Azure Functions auto scale. But SMS gateway is a place for concern, which we should make sure we choose the best provider, and best plan to accommodate the load.