Designing stateful system

Imagine you are a VP of engineering . Massive sporting event is scheduled and tickets of that event are going live on app/webapp. Since event is so popular, tickets are going to get sold out in few minutes. As a VP, you need to ensure — booking of tickets go well with great end user experience

Disclaimer: Techniques described in this article are based on my understanding and experience. Before picking these techniques, evaluate your use case and accordingly take a final call.

Technique 1:

Before we learn this approach, one note to be taken, this architecture is very high level. Using this approach, to meet that requirement we have cluster of DB, distributed cache, multiple instances of API(probably managed by an orchestration platform). We can even put queue here to reduce load on DB for write operations. This approach is completely fine and will work as well. However, it increases load on DB, one might face issues related to cache coherency etc. but can we tackle this problem statement differently? Yes. Virtual actor model system to rescue.

Before moving to next technique, in above technique — one thing to observe is that state is kept different from compute i.e. APIs are stateless and DB purely holds the state and virtual actor model system challenges this belief and takes a different route.

Technique 2 :

hahahah! I hope I have caught you off-guard with this architecture diagram. Again this is very high level diagram but enough to describe our approach. Before we learn this approach, we will learn what are virtual actors first!

Virtual actors are like in memory objects. They can hold state, they can perform task, communicate with other each other and one virtual actor can create another one. But how this fits in our problem statement? Imagine there are 30K tickets for the event which will make 30K virtual actors in our system. Each ticket as an virtual actor(object)which holds its state(whether it got booked or not , who has booked it etc.), each virtual actor will have methods like process payment, send notification(basically tasks). Careful reader will have a question in his/her mind if virtual actors are like shared in memory objects, how concurrency is designed? Every virtual actor has mailbox or queue like structure and actor processes one message( like update state A to B) at a time(single threaded) so no external concurrency constructs are required. Since I have mentioned above that they are like in memory objects what if servers go down? virtual actors can be persisted in traditional DB as well however virtual actor model system/runtime will try to keep cold state in DB and hot state in memory. Hope this resolves all initial doubts.

With this technique, we will create virtual actors(based on no of seats/tickets). First request to come to virtual actor’s mailbox will alter the state of the virtual actor(i.e. seat/ticket getting booked) and asynchronously system/runtime will persist state of the grain in DB. Very important understanding here is our middle tier/API layer/system layer is stateful and due to this property of the system — scalability and performance is massively improved.

Hope you enjoyed reading these techniques

~ Happy coding

P.S In this article, we introduced totally new method/path to design a system, hence treat this article as a step1 and there are many more such steps. Readers might have questions like can we make these in memory objects(virtual actors) distributed(spread across multiple app servers? and answer is yes), how to deploy such system, which persistence storage to use? All these questions can be answered using below links.

https://youtu.be/7erJ1DV_Tlo
https://youtu.be/wnBXrG8IS10
https://youtu.be/Z3R6EqIxmXg
https://youtu.be/9qUfX3XFi_4
https://youtu.be/R0ODfwU6MzQ
https://youtu.be/8duFuggnj8o
https://youtu.be/da9u5tqw-eo