An Introduction to Reactive Commerce
How to Invigorate Digital Commerce by Applying Reactive Microservice Architectures and Where it Makes a Difference
If your commerce platform is a critical, revenue driving component of your enterprise and either the nature or scale of the services it provides are difficult to predict and/or your ability to optimize the end users’ experience relies on near-real-time responses to rapidly changing signals, you should care about reactive commerce. Reactive commerce refers to the orchestration of services related to digital discovery, selling, purchasing, and merchandising of goods and services while conforming to principles of the Reactive Manifesto. Reactive commerce platforms are cloud-native and domain-driven by design and composable in nature. As such, they are ideal for enterprise-grade, high-performance eCommerce applications on mobile, web and native clients. Reactive commerce platforms are responsive, resilient, elastic, and fast. They are composed of microservices and conform to best practices of reactive microservice architectures (rMSAs). As of this writing, there are scores of commercial and DIY commerce platforms and a handful of commercial platforms built on microservice architectures (MSAs), but only one built on an rMSA. Operators willing to do their own stunts — and plenty can and are — may build reactive commerce systems if they need. Let’s unpack the thesis to understand why they might.
If your commerce platform is a critical, revenue driving component of your enterprise…
This is an easy one. If you sell fancy cupcakes, made fresh every morning, and close at 3 p.m. or whenever you sell your last delectable, you are wasting your time thinking about architecture. Consult a local agency about your company’s digital identity and if the juice is worth the squeeze, leave the tech up to them. If, on the other hand, an outage in any of digital commerce services can impact your revenue stream significantly, you should care about responsivity and resilience. A responsive system is alive, functioning, and available. A resilient system remains responsive despite faults… which always happen. If it can’t monitor and fix itself, one must have people who do. That’s a business decision and has nothing to do with technology.
…and either the nature or scale of the services it provides are difficult to predict…
This one is a bit more nuanced and should be discussed over a pint of Guinness, which takes about two minutes to pour. One bartender at a pub with a single tap dedicated to pouring Guinness cannot serve more than 30 pints an hour. If more scale is needed, more taps are required. More bartenders will not help scale the response for higher Guinness demands but may help scale services of another nature… like pouring whiskey or taking orders for curry fries. A good pub keep will equip, stock and staff (and make regular changes) to handle predictable clientele demands… they might call in extra staff if they know there’s an event in the neighborhood and they’ll hustle when they get swamped. Digital commerce operators must do similar; therefore they should care about elasticity and resilience. An elastic system scales up and down in response to and in pace with demand; up to ensure responsivity, down to minimize waste. If it can’t scale and balance itself, it must be managed by operations.
…and/or your ability to optimize the end users’ experience relies on near-real-time responses to rapidly changing signals, you should care about reactive commerce.
Now we are talking about the speed of dynamic orchestration, and this is not something operators usually need to worry about until they have stabilized their systems and have optimized experiences for their most valuable users on the most heavily utilized clients. There are tremendous opportunities to grow one’s business and tune delightful (and profitable) experiences of known segments through scripted interactions. But if investing in AI- or ML-based solutions to do just-in-time personalization, campaign management, recommendations and/or price optimization, one should consider how long it takes for their system to pivot in the presence of a new fact. If doing better on the next user like this one, or when this customer next visits, is good enough, no need to worry just yet. But if planning to impact the next request or even just the current session, or if choking on big data, one must care about the speed of state management and communication. If state is managed by a monolith in a disk-based data store, the speed at which a system can zig versus zag cannot be faster than the roundtrip transactions to update and query that state. State orchestration across multiple independent services can be faster if all services utilize in-memory state management and communicate changes with speedy non-blocking messaging techniques. However, it may be much slower if those services are just “pretending” to be microservices and rely on disk driven state.
In short, migrating to a reactive commerce platform is a valid solution for organizations struggling with reliability, availability, scale, and/or performance. Though not the only solution, it has great potential for lowering operational costs and leveraging just-in-time signals to provide reactive experiences required for truly intelligent commerce on digital channels.
Unsurprisingly, there are three ways to get it: master the principles and build it from scratch, develop a custom solution on a reactive platform, or more recently, buy (or rent) from your friendly neighborhood reactive commerce provider. Full disclosure, as I write this, I work for one of those, RETISIO… the only one, as far as I know. Reactive commerce was not our goal but a requirement for our desire to deliver a truly intelligent commerce platform. If you’d like the whole pitch, please visit retisio.com. This article is about reactive commerce in general and why we had to build it.
Developing a reactive commerce platform is not for the faint of heart. The commerce part, while large, is a mature and universally understood domain, but the reactive part is a bit tricky because it’s neither an architecture nor a platform but a commitment to meet behavioral requirements across the system. There are reactive platforms out there — we started with Lagom, by Lightbend, the leaders in the space… there are more options from Lightbend and others… and plenty of literature on the web — but one can use such platforms and still fall quite easily into old habits that subvert the end goal. We have had our struggles.
Committing to domain-driven-design (DDD) and rMSA was a big help and a huge departure from the legacy approaches of the n-tier powerhouse solutions that had survived and dominated post-dot-bomb. Reactive microservices (of which rMSAs are composed) are microservices and so follow the same principles of autonomous service, single responsibility, and exclusivity of state management via polyglot persistence. The same arguments used to describe the benefits, drawbacks, and ideal use cases of MSAs also apply to reactive microservices. We certainly capitalize on the advantages, if not the press, that MACH has to offer. Being cloud-native allows our licensed customers, (and us, as providers,) to leverage distributed elastic services from cloud providers when it makes sense but being reactive internally prevents our being reliant on any one cloud or container manager. Being API1st allows us to support custom tooling, ease of integration, and client composability and CI/CD integration (or headless, if you like) for suite customers. We certainly leverage platform composability as providers and share that with our customers who consume our components à la carte.
But one, or even several, reactive microservices does not a reactive system make. An elastic cart and registration service may be enough to handle the spike of requests driven by folks playing with IoT gadgets received on Christmas morning but is it enough to market, recommend, and cross-sell those same gadgets on Cyber Monday? Recall, we set out to be purveyors of intelligent commerce. One can’t have intelligent real-time experiences if they aren’t reactive to real-time signals, be they sourced from analytics or artificial intelligence. We must be state-driven and cope with near instantaneous changes to that state to provide predictive recommendations and personalized search optimizations that are informed and adapt to customer behavior, inventory status, geographic idiosyncrasies, and so forth. It’s a journey that requires reactivity at each step and along the whole road.
As already stated, being reactive is a requirement of our mission to deliver a truly intelligent platform for digital commerce; we continue to endeavor to do so. But we have found our commitment to reactive provides operational and economic advantages to managing eCommerce even when just-in-time experience optimization is discarded. That is why, at RETISIO, we believe anyone, “doing digital commerce,” that is too busy managing rolling restarts, holiday scaling programs or similar sources of repetitive stress, to grow the business, (or just keep the lights on,) could be interested in reactive commerce but those who are striving for real-time intelligence must be.
