Strangulating the monolith to a pluggable and scalable architecture

Global Technology
McDonald’s Technical Blog
4 min readFeb 27, 2024

By extracting microservices from the monolith, McDonald’s developers are creating apps that are more portable and resilient.

by Tasneem Damen, Principal Architect

Many remarkable frameworks exist for greenfield software development but are not always viable for a big-bang replacement of proprietary enterprise applications. Hence, this post will focus on applying strangulating patterns and engineering techniques for brownfield innovation.

Let’s look at the app our Owners/Operators use to manage restaurant systems. The application is a read/write heavy configuration management monolith, peaking at 400 MB/sec daily for a few hours per day, per country. The batch-oriented architecture lacks API-based communication, and the configuration data contains information with varying context and cache expiration periods.

As a result, there are disparate caching layers for millions of consumers, making the end-to-end cache invalidation time hours. A disparate caching layer on the batched data can also make governance challenging, as global market teams from over 100 countries must align to accept information metadata changes.

Approach
A logical start is to look at the information context — curation and authoring process — to bound it effectively. Looking at domain-driven design principles for quick service restaurants and retail domains and following the Pareto Principle, consumer menu management carved out as a series of core and supporting sub-domains is an ideal candidate for strangulation¹.

The batch generation process within the monolith lends itself as a façade, aggregating data from new API-driven domain services to generate the batches, consumed by data movement service for the downstream consumers. The batch generation façade enables gradual business unlock for both upstream and downstream consumers, while remaining backwards compatible. New domain APIs follow McDonald’s standardized ontology while batch generation uses an adapter² pattern to ensure stability for the existing consumers. Moreover, feature flag strategies are also implemented to canary the façade rollout to further de-risk the adoption process by McDonald’s markets. Half of the McDonald’s stores use this capability on daily basis across the globe.

Batch generation, a compute-intense process, modeled as a microservice, enables optimization of daily burst-out scale and independent release management cycles.

Containerizing the batch generation service allows for horizontal scale-out of the storage and computing without incurring the costs of vertically scaling the entire monolith or creating dedicated instances per country. Currently, we use KEDA’s event-driven pod-scaler to provide burst-out scale to maximize resource utilization.

Outcome

True MACH architecture
With the strangulation in place, the business domain and corresponding capability can now be treated as its own product, free from past constraints, to redefine its business excellence. Its architecture can be Microservices-based, API-first, Cloud-native, and Headless (MACH), which differs from the monolith architecture but follows Twelve-Factor App methodology — a methodology for building software-as-a-service applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.

Governance and standardization
A strangulated business capability provides more tools for solving a business problem than implicit conventions of the monolith.

For example, user experience can solve for omnichannel vs. multi-channel menu management strategies. Moreover, core domains with semantic API versioning can iteratively introduce changes globally. Creating a single source of truth minimizes the overall complexity in the end-to-end architecture — from the time a business user authors to when an end consumer sees it on their devices.

Changing business SLAs
Switching from a batch-oriented architecture to an API-driven architecture means new service-level agreements (SLAs) for the new domain microservices receiving consumer service requests throughout the day.

Using batch generation as the first consumer of the domain API helps validate the internal scale-out strategy before syndicating to other external consumers. Pre-cached channel-specific menus are provided from edge nodes, which when coupled with smart validation and delta caches, may exponentially reduce the entire network throughput.

Consumer adoption
As monolith applications are inherently more complex to change, new feature requirements are developed in the new domain microservices and served to consumers over secure APIs with real-time event notification. Consumers are better positioned to honor the service-level objective and request bug updates and enhancements to fuel McDonald’s innovation. Ultimately, this helps unlock new business value and drive the consumer adoption.

¹Strangluation is a software design pattern where the existing system is put behind an intermediary façade or wrapper. Over time new services behind the façade start to replace capabilities of the old system. The process is repeated until the old system is fully strangulated into new services.

²Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate. In this instance REST JSON objects are converted into XML documents.

--

--