# Choosing the Right Granularity for Microservices: Klarna's Payments Architecture Journey

DevFeed: [Choosing the Right Granularity for Microservices: Klarna's Payments Architecture Journey](<https://devfeed.tech/articles/how-micro-should-your-microservices-be-35650.md>)

Original publisher: [Read original article](<https://engineering.klarna.com/how-micro-should-your-microservices-be-9ae7507a625c?source=rss----86090d14ab52---4>)

Author: Raya Rizk

Published: 2025-03-24T07:22:27Z

Content type: article

Language: en

Sources: [Klarna Engineering](<https://devfeed.tech/sources/klarna-engineering.md>)

Topics: [Microservices](<https://devfeed.tech/topics/microservices.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [challenges](<https://devfeed.tech/tags/challenges.md>), [distributed](<https://devfeed.tech/tags/distributed.md>), [klarna](<https://devfeed.tech/tags/klarna.md>), [led](<https://devfeed.tech/tags/led.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [modular-monolith](<https://devfeed.tech/tags/modular-monolith.md>), [monolith](<https://devfeed.tech/tags/monolith.md>), [organizational-structure](<https://devfeed.tech/tags/organizational-structure.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>)

## AI overview

This article describes Klarna's transition from a monolithic architecture to payment-specific microservices and examines the trade-offs of service granularity. It reports that independently managed services improved team autonomy and development speed, while duplicated shared functionality created a complex distributed monolith.

## Source excerpt

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