3. Microservices Realities: Rethinking the Architectural Trade-offs
Microservices promise agility, flexibility, and resilience — but in practice, these benefits often come with hidden complexity. This article explores where microservices deliver, where they fall short, and why Transacumen built Stratum instead on a hybrid architecture.
By Craig Worrall,
Founder and CEO
This is the third instalment in our four-part series on software architecture.
In our last article, we revisited the monolith - not to refute its limitations, but to reframe the conversation. In this piece, we turn our attention to microservices. Much has been written in favour of the microservices model, but in practice, many of its perceived advantages prove more conditional than categorical.
For all the industry enthusiasm, the core benefits of a microservices architecture are surprisingly narrow. And even those benefits come with trade-offs that are frequently underestimated.
What Microservices Actually Offer
At a high level, the architectural promise of microservices rests on three primary claims:
- Independent Deployment: Teams can deploy and scale individual components independently.
- Technology Stack Freedom: The flexibility to use different programming languages, libraries, or frameworks for different system components.
- Fault Isolation: System components are deployed separately, containing the blast radius of failures.
Let’s take a closer look at each.
i) Independent Deployment: A Double-Edged Sword
Independent deployability is often cited as the most compelling benefit of microservices. In theory, it enables faster iteration, reduced coordination overhead, and safer releases.
But in reality, this advantage is limited by the nature of the change. A bug fix or internal improvement might be deployable in isolation. A new feature or cross-cutting capability rarely is. Versioning, dependency management, data model consistency, and orchestration still require significant coordination.
Independent deployment also creates its own complexities: more pipelines, more runtime environments, more distributed state to track and manage. Without rigorous investment in tooling and process maturity, the cost of deployment freedom may outweigh the gains.
ii) Technology Diversity: Helpful, But Rarely Game-Changing
The ability to mix technologies can be helpful - especially if your initial tech stack proves suboptimal for evolving requirements.
But it’s rarely a driving force. Most high-performing engineering teams prefer standardisation across services. It simplifies hiring, onboarding, debugging, and allows shared tooling. In practice, teams only embrace technology diversity when the benefits of an additional stack significantly outweigh the associated development and operational costs.
iii) Fault Isolation: Useful, But Not Sufficient
Operating system-level isolation does reduce the risk of cascading failures. If one service crashes, others can continue unaffected - in theory.
In practice, the surrounding system still needs to handle unavailable dependencies, propagate distributed system errors cleanly, and fail without corrupting shared state.
Isolation helps, but it doesn’t solve the problem. You still need to design for failure.
The Unfulfilled Promise of Microservices
As organisations evolve, they often encounter an unexpected reality: microservices don’t inherently deliver the agility, scalability, or resilience they were promised. Why? Because these outcomes depend more on organisational factors than architectural choice.
This gap between expectation and reality has been well-documented. Many teams adopt microservices prematurely and find themselves saddled with operational overhead and technical debt. Development of new features becomes slower and more expensive; agility decreases; and business opportunities are lost.
A Problem of Framing
Part of the issue is the question itself. 'Monolith or microservices?' is often framed as a binary decision. But the optimal architectural choice is a function of a constantly evolving landscape: team size, product maturity, scaling constraints, talent availability and demands from stakeholders.
Leading architectural thinkers increasingly argue that this isn’t the right question at all. Instead of selecting between two imperfect models, we need new frameworks - ones designed to navigate complex tradeoffs rather than dictating rigid, short-lived solutions.
The Transacumen Advantage
Fueled by the above insights, Transacumen embarked on a novel path to architecting Stratum - our payments hub and switching platform.
We approached the problem from first principles, asking: What core capabilities are essential? What organisational and technical constraints must we address? And critically, how adaptive does the architecture truly need to be?
The result is not a monolith, and not a microservices system in the conventional sense. It is a hybrid model: one that draws selectively from both patterns while rejecting the rigidity of either.
This decision was grounded in real-world implementation experience: multi-party integrations, 24x7 uptime expectations, and complex payment transaction requirements. Environments where neither pure monoliths nor full-service decomposition microservices held up over time.
Up Next: An Overview of Stratum's Architecture
The next article will dive into Stratum’s hybrid architecture - what it's capable of and how our customers are benefiting.
Transform Your
Payment Processing Today
