Yet Another Virtual Queue Management System Design

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.

Table of Contents

  1. Requirements Gathering & Analysis

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.
  1. User visits the App

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:

  1. App for Smart Phones — for Customers

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:

  1. Token needs to be auto generated and make sure no two customers gets the same token.

Performance benchmark for solution:

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

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.

  1. Scalability — Number of hits matters

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.

Microsoft Azure Solution:

AWS / Amazon Web Services Solution:

The Docker way.

You can read the paper in my GitHub repository as well.

References

Program Director at Adfolks | Technology Enthusiast, Microsoft rMVP, PMP

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store