The last thing a piece of software wants to be called is a “monolith“. “Monolithic” sounds a bit too much like “paleolithic” – evoking images of a prehistoric and unwieldy system. Then there’s the concept of “microservices” which promise scalability and success – even at Netflix scale. There are lots of articles on the monolith vs. the microservice, but here I want to consider these paradigms in the context of enterprise point of sale and our new product, JumpMind Commerce, specifically. Read on to learn how we leverage microservices even while supporting robust offline functionality.

Quick Monolith vs. Microservice Primer

The choice between a monolithic vs. microservice-based architecture has implications for your development team, release schedule, development costs, and much more.

In a nutshell, a monolith is an application where all the business logic and data access (and potentially UI) are rolled up into one bundle of an application. One big team tends to work on it.

On the other hand, instead of being one large app, a microservice-based application distributes logic, often by business domain, across multiple, independent services, each with its own data store.

Here is a simple comparison of the same app in the monolith vs. microservice style:

Here’s a quick comparison of how monolith and microservice approach certain topics:

	Monolith	Microservice
Scaling	Entire application scales as a unit	Individual services can scale vertically or horizontally, as usage dictates
Dev Team	Requires broad expertise to comprehend the breadth of the system	Smaller teams can focus on one, simpler service area
Releases	Less frequent and higher risk because the whole application is released as one unit	Individual services can be released more frequently. CI/CD is more manageable with smaller units
Complexity	A monolithic is simpler and more rapid to develop for smaller systems	Large, complex systems benefit from microservice architecture because the complexity is cleanly divided by service
Tech Stack	Tends to be a single tech stack on one VM to run the application	With microservices – since each area of business functionality lives behind an API – different tech stacks can be used where it makes sense
Database	Usually one big relational DB	At least one DB per service, more flexibility to use a variety of database types
Purity of Boundaries	The boundaries between business domains (e.g. Customer vs. Order in an e-commerce system) will blur over time	Microservices enforce separations between business domains
Runs on	1 machine	Multiple VMs

Microservice Promises and Challenges in Enterprise Point of Sale

The promises of microservices are most welcome in point-of-sale: rapid deployments, scaling only what needs to be scaled (e.g. giving more processing power to promotion calculation), horizontal database scaling – just to name a few. You can picture how this would be accomplished on the backend, services side:

So far so good, but point-of-sale is a mission-critical, in-store application that often needs to run offline.

Some vendors punt, offering significantly reduced functionality when running offline. With that approach, you have your microservices access when running normally/online, but fall back to simplified functionality in a small monolith application that runs in the store. I see several issues with that. Most obviously, it would be ideal to have roughly the same functionality whether online or offline (think complex tax calculations, promotions, etc.) Also, there is duplicated effort to build the true functionality into the microservice, and then the diminished functionality into the offline app, and as soon as there is business logic duplication – there is increased testing time and more bugs.

JumpMind Commerce Microservice Approach

When we laid the groundwork for JumpMind Commerce, a microservice architecture was a priority. Some services like promotion or tax are prime to be shared between ecommerce and store systems, and have different scaling profiles from other services like customer lookup.

But the question remained of how to handle offline situations. That is, when JumpMind Commerce is offline from the central microservices and has to run in a local, self-contained mode, how is that accomplished?

For this, we opted to take a “pragmatic approach” to our microservices, meaning that the services are designed to run independently as pure microservices OR in the same VM, with any combination possible. This allows the microservices to be bundled together and formed into an application to run on an individual cash register instance.

You could call this a hybrid approach to microservices, and for POS I would argue it’s ideal if you need to enjoy the benefits of microservice architecture in the cloud and at the same time support full offline functionality in the stores. To accomplish this, our microservices adhere to the following principles:

No reliance on a particular cloud provider or technology. A JumpMind service needs to be able to function on any commodity PC. In the cloud, we run on GCP, AWS, Azure, etc. because of this “vanilla” approach. In implementations, we often use Docker and Kubernetes for orchestration and scaling.
Services only interact with each other via API. No cross database access is permitted.
Services share a basic Java / OpenPOS stack. OpenPOS is JumpMind’s framework for building retail applications, providing building blocks like data access, caching, i18n, currency, etc. In the future, a service could use a different stack provided the stack doesn’t depend on any particular cloud technology and can run on a stock PC. I think it’s pragmatic to share some basic stack components. It would be unnecessarily complicated for a package such as JumpMind Commerce to choose different programming languages, databases, etc. arbitrarily for different services. That said, when the need arises to pivot any of our given microservices to alternate stacks, the opportunity is there.

JumpMind Commerce has sophisticated orchestration logic built-in to support this model of hybrid microservices:

Services are designed to be cloud-agnostic, as well as agnostic to whether they are running in a store or in a cloud (or on-prem data center). The orchestration layer determines the optimal path for a service call: remote, local, local then remote, remote then local, etc. It could be over REST or it could be an intra-process call for efficiency. This is all transparent to the services – they behave the same way in the cloud or in the store.
In order to provide robust offline services, one significant challenge is getting all the relevant data down to the stores. JumpMind Commerce comes with the industry-leading SymmetricDS data sync engine embedded in the fabric of the application. JumpMind has over 14 years of experience replicating data on a wide scale and we are able to leverage this experience to make sure all the distributed services have just the data they need.

One last comment on the advantage of microservices in enterprise point of sale. I have worked on several large-scale monolithic applications in my career, and while they were all high-quality, inevitably the business logic domains do bleed together over time. Worse, business logic blends with application flow logic, and even UI logic in a monolith. So when the time comes to reuse that business logic in another context, it’s just not possible because it’s so embedded within the assumptions of the original application (think one line of code calculating a total, the next line of code requesting to advance the screen, etc.)

One key advantage of the JumpMind architecture is that microservices are purely devoted to business logic, without the chance of being contaminated by other services, application flow, or UI concerns. Having your business logic clearly and cleanly expressed this way opens a world of possibilities for the omni experiences shoppers expect in a post-COVID world.