The Curious case of Stateful Architecture!

Logic Keepers

Introduction

As an Architect, when we start working on a new application or solution architecture; we study the requirements and see if the solution requires maintaining a specific set of states to support a business use case that requires maintaining a workflow or a state-machine (Event-Driven).

Now, this is the tricky part; many would consider the application is stateful only, if you need to maintain the state in memory, but if you maintain the state in the Database, then it’s stateless.

However, in reality, if you have a state to manage, then whether the state is in the Database or it’s in the memory, it’s Stateful.

The Case for Stateful Architecture

Working with many applications in production, most often, at one point, you would realize that, maintaining the state in the database, has performance and scalability limitations.

For the sake of simplicity, we will talk about performance and scalability as the supported number of transaction or requests/responses per time, for example supporting 10,000 transactions/second.

There’s a magic number of TPS that is associated with a certain performance, scalability and Return-on-Investment (RoI) requirements -especially in the Cloud-. That magic TPS number; your application will not be able to meet by loading the state from the database for every arriving request.

As a simple example, an eCommerce order that starts with building a simple shopping cart, would have many states , steps and a lot of data. Loading the order from the database for every request is going to be a significant burden on the system.

Databases are bottlenecks and a cost burden, it’s still a limitation we usually miss that is similar to the 100% network reliability. In the last decade, we made significant progress in the IT world, however, we are still operating within those limitations.

Stateful in the New World

The need for cost reduction, responsiveness and elasticity is exponentially amplified in the modern world.

Web is not the only channel anymore, Modern Application Architecture is utilizing Hexagonal Architecture, APIs and Reactive Architecture to cope with the new pace of business requirements.

The performance and the scalability (TPS) magic number that we referenced earlier, where you would need to switch from a simple architecture to stateful architecture is something you would hit fairly quickly in this world.

If you have 10 backend APIs that are hit by 1000 Apps concurrently; you would be required to support 10,000 TPS fairly earlier than what we used to -within the life-cycle of the application-.

The Stateful Options

We are familiar with the obvious stateful options where we separate our application logic or Microservices from the state, where we use a distributed cache or in-memory database to support the in-memory state.

How about combining both the behavior and the state cache in one container, imagine the maintainability, simplicity and the performance gains we would reap from such an approach. That would be a single unified resource, no synchronization or data exchange required between two different systems.

This is the beauty of the “Actor Model”, it combines both the state and the behavior in a single object, eliminating the need for maintaining a separate cache.

Akka, is a mature and battle-tested implementation of the Actor model that has both Java and Scala APIs, for more on Akka, follow the link here, Akka is an open-source implementation, but if you’re looking for an Enterprise Support, this is the link to Lightbend, the powerhouse behind Akka.

Stateful Architecture Use Cases

Now, how about the Stateful architecture business use cases? Is that only for the Amazon likes and the Streaming companies? If you didn’t get the chance to work with one of those yet, we don’t want to leave you wondering what that would be?

Below are some of the clear use cases where it would quickly force an Architect to adopt a Stateful Architecture.

eCommerce & Retail

Order Management, KYC, Upselling, Product Smart Search, Supply Chain and Inventory Management, and Intelligent Customer & Support (Chatbots).

FinTech & Financial Services

Loan Approvals, Anti Money Laundering (AML), Risk Management (Event Coordination & Predictive Analytics), Trading (What If Portfolios) and Payments.

Telecom & Internet

Mobile Devices Management & Tracking, Messaging, Device Dependent Mobile Apps, GeoLocation and Maps.

Hospitality, Grocery & the Food Industry

Food Delivery, Supply Chain, Gig Economy Applications (Helpers).

Internet of Things (IoT)

Devices, Devices, Devices, IoT, ML and Analytics are now involved in almost every industry, this is not just Smart Homes or Alexa anymore. We can’t keep track of those devices using a traditional database.

Information Security

Attacks are becoming more and more sophisticated and coming from various directions at the same time, security applications are constantly utilizing stateful architecture and event sourcing to support predictive analytics to stop those attacks before they can cause considerable damage.

Social Media & Entertainment

Messaging, Collaboration Tools, Media Streaming, Smart Media Search, Smart KYC, and User Preferences.

Others

Those are just few examples on the business use cases, leaving out Government and Health and many more, we can spend days on this list, I’m sure we are going to get a lot of input and feedback on other business use cases and other industries, also, many comments on the breaking down of the grouping of the industries mentioned above.

About Logic Keepers

Logic Keepers is a Software Development and Technology Enabled Services Company, bringing back the logic into Cloud-Architecture and Fast Data, educating the IT community about the tremendous value of Cloud-Native Architecture, Reactive Architecture and Reactive Microservices.

We accomplish this by following a balanced pragmatic approach, you can’t just introduce the concept without providing the use cases and the implementation.

If you lean too much on just the concepts, then it’s theoretical or if you go too far on the infrastructure side of things such as K8S heavy, then it’s more of a DevOps exercise and leaving the developers behind.

Check for more information here on how we accomplish this in our Modern Application Architecture Workshops.

This is not just about knowledge, you have to include coaching and mentoring as well in your learning plans.