In the world of software development, not many voices are as certain and as distinct as that of Asiru Erioluwa.
A top rated software engineer with a profound expertise in distributed systems, Erioluwa combines a unique blend of low-level practicality and high-level vision.
Recently, his focus has shifted toward one problem that ails even the best-optimized systems: data gravity.
It is a word that emerged in the early 2010s and is used to speak of the way programs and services become drawn to ever greater amounts of data, a planet attracting objects into orbit.
For monoliths, this had been an observed pattern, one that all too typically resulted in coupling and less agility. For microservices, however, with independence and modularity as objectives, the problem that ensues is more nuanced and more pernicious.
“Microservices provide you with independence but tend to end up relying on a single source of truth,” according to Erioluwa. “And that truth is within a monolithic database.”
It starts innocently: one or more services share a common database for the convenience of synchronization in real-time or for legacy circumstances.
More and more services get added along the way, reading and writing the same stores.
Soon, these services become monolithically coupled to the database. Integration tightens up, deployments get more synchronized, and failures become more coincidental. What should have remained a set of standalone services becomes a monolithically-coupled batch—operationally distinct, perhaps, but architecturally indistinguishable from a monolith.
Erioluwa does not dawdle over theory. Her conclusions result from having led high-impact engineering teams that have already weathered these waters.
She has lived the consequences of fuzzy data ownership when the allure of “just plug into the same DB” prevails over long-term design principles.
And she has helped teams get themselves out of the hole they’ve dug themselves into, reinserting boundaries into services not in ivory-tower abstractions but through laborious redesign of data flows and ownership.
One of her responsibilities involved untangling a microservices architecture with nearly all the services coupled tightly against a monolithic PostgreSQL database.
The performance issues pervasively filled the system. Schema changes had to be performed with precision for fear of causing a cascade of failures.
Erioluwa’s approach was meticulous: implement true data ownership, decentralize storage responsibly, and scale with asynchronous messaging when consistency might be relaxed. It wasn’t glamorous.
“It worked. Data gravity is not a negative thing,” she says. “You just need to recognize when it is warping your architecture. If your services rely on querying a central database before they get started, they’re not services. They’re clients.”
She indicates that it does not mean being event-driven or that it is adopting the newest technology. It means that one has to learn about trade-offs.
Accepting the cost of eventual consistency for independence. Being a thoughtful steward of the boundaries between services. And giving up convenience today for tomorrow’s maintainability.
Peers describes Erioluwa as a practical engineer who does not go with the trend but challenges the assumptions behind it instead.
She is a reminder that microservices cannot be a panacea. Lacking discipline and rigor of architecture, they will reproduce the same problems they aimed to solve, but with added complexity.
As the topic of modern software architecture comes of age, people like Asiru Erioluwa are priceless. Not merely does she preach good practice, but she lives it.
And in the process, she keeps teams grounded even when they’re dealing with the complex realms of distributed systems.
