Scalable Microservice Architecture

Application State Management and Data-Driven Decision Making

As the complexity of applications and systems increases, the size of the teams that work on these also increase. In these scenarios, having the system as a monolithic one inhibits the development team from being able to move forward at speed. This gave rise to the need for an approach that would allow independent functional teams to be able to deliver their functionality in its entirety with minimal (if any) dependency on other teams. This goal has been attempted to be addressed from the beginning of time: think of Object-Oriented Programming, Service-Oriented Architecture, Enterprise Service Bus and now microservices.

Real-World Example Problem

The premise of microservices is that everything related to a functionality should reside in a self-sufficient manner. Think of a monolithic application eCommerce application (albeit, super simplified scope) that has the following modules:

Each of these functions could have different utilization levels and to have an entire application to scale to the maximum level is going to be consuming resources incongruent to utilization. A person logs in once per session but could end up searching many times, updating their cart less frequently, ultimately checking out only once. Perhaps, then the user logs out after checkout. In this case, the search functionality and inventory check functionality would be used a lot more than the others. By breaking down the application into self-sufficient services, i.e. microservices, the appropriate service can then be scaled according to the load on the function. But that fully self-sufficient nature means that each of these services have their own end-to-end full stack of technology, including the database. If the data is common between multiple services, the database layer gets extricated out of microservices in favor of the creation of a common, shared data layer. This allows a consistent implementation of the Saga pattern where the participating services can then signal each other and operate off the same database.

Problem Solved, Right?

Close, but not quite. There are further requirements for high performance in the following:

• Financial Services:
  • Credit card fraud prevention
  • Portfolio risk management
  • Real-time slippage calculation
• eCommerce
  • Real-time inventory management
  • Real-time order management
  • Search consistent with inventory levels

In these use cases, data processing usually has less than a 5 milliseconds latency budget. This is where the popular notion of separating data and business logic starts needing a little refinement into two kinds of business logic:

1. Application state control business logic application logic stays with the application, i.e. the microservice, and
2. Data-driven decision making business logic data-driven business logic stays close to the data, i.e. in the database.

This kind of a separation allows both layers to scale independently according to the performance needs of each while not creating either an inconsistent/diverging data set or a multi-layer, stitched-together approach where the infrastructure footprint bloats artificially to ensure resilience at each layer.

Where Does VoltDB Come In?

VoltDB is a distributed in-memory database that is designed to power real-time intelligent decisions on fast moving streaming data. With the stored procedures framework, and the in-memory data storage engine, VoltDB drives most complex business logic in the lowest latency in a scalable manner, even in a virtualized environment like VMs and containers. All this without compromising on the ACID guarantees that are expected from an enterprise-grade database. If you are in your journey of moving your applications to a microservice architecture, give us a shout to see how we can help meet your data processing needs with cross-functional consistency.