How micro should your microservices be?
Our journey towards striking the right balance
The debate between monolithic and microservices architectures is a hot topic in software development. While monolithic systems are known for their simplicity and tightly integrated structure, they face challenges with scaling and flexibility. In contrast, microservices offer greater scalability and autonomy in development, but carry complexity in inter-service interactions. In this article, I’ll share our experience in navigating between these two paradigms while working on a recent project at Klarna, exploring different architectural decisions while addressing a fundamental question: what is the optimal granularity for a microservice?
From monolith to microservices: the company is growing 🚀
A monolithic architecture is often the natural starting point for businesses, serving well initially but revealing its limitations as organizations scale. Klarna was no exception. Like many in the IT industry, the company embraced the microservices paradigm alongside its rapid growth a few years ago.
In the payments domain, we are focused on offering customers various payment options, allowing them to choose between paying directly, later, over time, or through other tailored methods. This demand for diverse options led each payment method to evolve into a distinct microservice, managed by dedicated teams. Each payment service acts as a key orchestrator in the purchase flow, coordinating with other services to guide customers through the required steps until order completion.
This adoption of microservices naturally aligned with the company’s organizational structure, offering team autonomy and the ability to scale services independently. Each service was self-contained, with its own database and code residing in a separate repository. By decoupling payment options into distinct services, we gained greater flexibility and enabled faster development cycles, as teams could focus on their respective components.
Landing the distributed monolith: a complex setup 🏗️
While the different payment options at Klarna serve unique purposes, they share underlying similarities. Regardless of the payment option a user selects, the end goal remains the same: “to pay”. Certain checks and steps are common across all payment options, such as user authentication, funding source collection, and risk assessment.
Since the microservices were handling similar functionalities, any new requirement had to be implemented across all services. Additionally, changes or maintenance needed to be executed multiple times by different teams. This led to numerous instances of duplicated code, challenging maintenance, scalability issues, and the unexpected cost of managing multiple services.
This situation raises critical questions: Do we really require microservices? Or has our excessive division led to the creation of a distributed monolith?
Microservices excel when applied to truly independent business domains with distinct scaling needs, separate release cycles, and autonomous teams. However, our use case was different — we encountered shared business logic, interdependent features, and similar scaling patterns. This, unfortunately, resulted in us creating a distributed monolith, with an ever-increasing complexity due to multiple codebases, databases, and deployment pipelines. The organizational impact was significant, as teams spent more time coordinating changes than delivering value, while struggling with the cognitive load of managing multiple services.
While microservices may appear well-suited for diverse scenarios, they are not a one-size-fits-all solution. Sometimes, even the best-intentioned implementations can lead to unforeseen costs. Adopting microservices, or any solution for that matter, can address certain challenges but may also introduce new, complex ones.
From microrepos to monorepo: a recovery attempt 🚑
In an effort to address the issues we faced with our microservices setup, we attempted to share common functionalities across services by reverting to a monorepo structure while keeping the services separate. The monorepo aimed to centralize code management and reduce redundancy, offering easier collaboration and alignment across teams. However, this quickly resulted in a monorepo cluttered with duplicate code, making it challenging to navigate and understand. Extracting common functions was both difficult and error-prone. Although the functionalities were similar, slight variations in their implementation complicated the process, making it anything but straightforward. Consequently, the cost and effort required to manage and maintain this setup remained high.
While monorepos can facilitate code sharing and cohesiveness, they require strong governance and standardization across teams to be effective. Merely consolidating code without addressing fundamental architectural challenges proved insufficient.
From distributed monolith to modular monolith: a better future ☀️
Faced with the challenges of a distributed monolith, what options do we have? Should we simply revert to the traditional monolith we had, with all its known limitations? Not necessarily.
Instead, by carefully considering both business needs and technical contexts, and following Domain-Driven Design (DDD) principles, we can identify a more balanced solution. DDD emphasizes structuring software around core business domains, recognizing that the ideal size of a service often aligns with a broader business domain or entity rather than focusing on granular features. For instance, instead of concentrating on individual “payment method options”, we consider “payments” as a cohesive whole. This shift in perspective allows us to consolidate common functions and organize the system into well-defined modules that focus on shared features, resulting in a more appropriately structured architecture.
In practice, our modular approach goes beyond simply separating the available payment options (“pay now”, “pay later”, “pay over time”, etc.) into distinct modules. Instead, we break down the application based on features. This results in clearly defined modules addressing specific functions — such as authentication, funding sources management, and risk assessment, among others. Each module represents a specific business domain with clear boundaries and responsibilities, enabling better organization and maintenance of the system.
By dividing the large system into smaller, manageable modules within the same application and limiting interactions across their boundaries, we achieved the desired balance: one service, one database, and a structured, clean codebase. Each module operates within a well-defined context, enabling isolated development and testing while eliminating the overhead of remote calls and the duplicated functionality that is common in microservices. In other words: thoughtful modularization combines the simplicity of a monolithic architecture with the flexibility of loosely coupled components.
The benefits extend beyond code organization. The modular architecture enhances observability through standardized logs, metrics, and dashboards, eliminating the complexity of managing numerous service-specific monitoring solutions. This unified strategy simplifies troubleshooting while ensuring consistency across the entire system. Moreover, these well-defined modules become natural candidates for future microservices if needed, making the modular monolith an excellent foundation for incremental architecture evolution.
Although this approach has clear benefits, it also brings challenges. The modular monolith presents an increased risk of a single point of failure; if the application crashes, it can impact the entire system. Additionally, managing a unified codebase across multiple teams in a single monorepo requires clear standards and practices for coding, testing, and deployment. Coordinating development efforts, with numerous commits and simultaneous changes, requires robust communication and aligned release cycles.
The power of modularity: striking the right balance ⚖️
While we consolidated the payment services into a modular monolith, this single service itself remains a key microservice in the purchase flow at Klarna. It continues to both integrate with and be integrated by many other services.
A significant challenge remains in creating a universal payment flow that accommodates different payment options across various markets, each with distinct functionalities and market-specific requirements. The solution here lies in customization through configurability. By developing one configurable flow, we can create a versatile set of features and steps that function like puzzle pieces or modular building blocks. These components can then be assembled and tailored through various configurations to efficiently support diverse payment options.
The migration to the single service is still ongoing, yet the new solution is already proving its effectiveness. By leveraging configurability, we were able to add new features to existing payment options and launch new payment options in various markets within days with minimal development resources — simply by adjusting configurations and running tests, many of which passed on the first attempt. Previously, such deployments would take weeks or even months, requiring coordination across multiple teams and extensive testing to ensure a unified solution. This streamlined approach has significantly reduced both time to market and resource requirements.
In terms of load, the service already handles over a million orders daily, demonstrating its robustness and scalability. This capability was put to the ultimate test during Black Friday, Klarna’s most challenging day for peak load and purchase volume. The system not only withstood the stress test but set a new record by processing one-third of all Klarna transactions that took place that day. Given this proven performance and significantly lower resource usage, the financial advantages become clear — why incur the overhead costs of microservices when a dynamic modular monolith can handle such scale efficiently?
We look forward to completing the full migration, which will enable streamlined, unified processing for all Klarna payments while maintaining optimal resource utilization.
Key takeaways: optimizing architecture choices 🎯
Understanding the nuances between different architectural styles is essential for making informed decisions. The following table offers a side-by-side comparison of microservices and modular monolith approaches, highlighting their strengths, challenges, and typical use cases.
In software development, cyclical trends are inevitable. As projects and organizations evolve, growth may necessitate splitting services again. By establishing a robust framework and embracing meaningful modularization — guided by Domain-Driven Design (DDD) principles and its focus on core business domains — teams can adapt their architecture to meet changing requirements without compromising system coherence or maintainability. The experience gained from modularization has revealed a key advantage: modules can be seamlessly extracted into microservices when needed. This flexibility enables teams to work within well-defined bounded contexts while maintaining the agility to restructure the system as necessary. Ultimately, this approach provides a sustainable path for continuous growth and innovation, allowing teams to navigate software development cycles with greater confidence and efficiency.
Acknowledgement
Many thanks to all the contributors for their support on this project, especially Alessandro Dal Bello, Batıkan Türkmen, Carlo Micieli, Francesco Maria Chiarenza, Mikael Vessgård, Niklas Peil, and Sanchi Goyal.
