# modular-monolith Published articles for modular-monolith. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## When Microservice Decomposition Is the Wrong Default DevFeed: [When Microservice Decomposition Is the Wrong Default]() Original publisher: [Read original article]() Author: Philipp Lehmann (philipp.lehmann@gruppe.ai) Published: 2026-08-21T07:00:00Z Content type: opinion Language: en Sources: [Philipp Lehmann]() Topics: [Microservice](), [Architecture & Design](), [Microservices](), [FastAPI]() Tags: [api](), [architecture](), [circuit](), [docker](), [microservices](), [migration](), [modular-monolith](), [monolith](), [openapi](), [tracing]() ### AI overview The article argues that splitting a small system into microservices should not be the default. It recommends keeping responsibilities in a modular monolith unless differences in scaling needs, organizational boundaries, or failure isolation justify a network boundary, whose costs include contracts, compatibility management, retries, timeouts, circuit breaking, and distributed tracing. ### Source excerpt import-linter forbidden contract as a module boundary: a FastAPI modular monolith instead of early microservices, and when a network split pays off. ## Modularizing SOLR Query Creation for Multi-Market Scale DevFeed: [Modularizing SOLR Query Creation for Multi-Market Scale]() Original publisher: [Read original article]() Author: Naman Parikh Published: 2026-03-03T12:18:55Z Content type: tutorial Language: en Sources: [Walmart Global Tech]() Topics: [Code](), [configuration](), [implementation](), [Testing](), [debug]() Tags: [article](), [code](), [complexity](), [configuration](), [developer](), [errors](), [exceptions](), [implementation](), [information-retrieval](), [modular-monolith](), [monolithic-architecture](), [regression](), [software-architecture](), [software-engineering](), [technical](), [testing]() ### AI overview This article describes modularizing a 12,000-line SOLR query creation implementation used across multiple markets. It explains how separating query concerns, adding market-specific configuration, and using stronger typing aimed to reduce coupling, regression risk, and runtime errors. ### Source excerpt Introduction When the SOLR query logic expanded into a 12,000-line monolithic implementation, each modification introduced significant risk, making every change feel akin to defusing a critical system. Adding a market-specific override required yet another if block, compounding complexity and slowing time-to-market. In this article, we will deep dive how we broke that SOLR query creation logic, enabling clean configuration per market, stronger typing, reducing technical debts and dramatically reduced runtime errors. Image generated with DALL-E via ChatGPTThe Problem: When SOLR Queries Creation Logic Become Technical Debt The SOLR query logic class was handling filtering logic, boosting logic, boost functions, pagination etc. All the parameters related to SOLR query was getting generated using single class. Overthe time, this core class handled various logics related to different type of queries: Primary search queries Item insertions via business tools Item insertions via semantic sources Thousands of lines tangled edge-case handling, scoring tweaks, and boosting logic. This unscalable approach: Blocked rapid iteration for new markets Tight Coupling: All query-handling logic lived in one massive class, making it difficult to cleanly separate concerns. Market-specific changes could unintentionally affect unrelated logic, requiring exhaustive regression testing. High Risk of Unintended Consequences: Changing business requirements (such as supporting different filtering or boosting strategies for a new market) entailed changing existing code that already served other markets. Developers had to be extremely cautious, as a bug or oversight could break unrelated functionality. No Configuration Flexibility: There was no clear system for externalizing market-specific configuration. Instead, all logic changes happened directly in code, preventing business users or product managers from making simple market changes without developer intervention. Increased Runtime exceptions ## Choosing the Right Granularity for Microservices: Klarna's Payments Architecture Journey DevFeed: [Choosing the Right Granularity for Microservices: Klarna's Payments Architecture Journey]() Original publisher: [Read original article]() Author: Raya Rizk Published: 2025-03-24T07:22:27Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Microservices](), [Architecture & Design](), [Development](), [Software Engineering](), [Scalability]() Tags: [architecture](), [challenges](), [distributed](), [klarna](), [led](), [microservices](), [modular-monolith](), [monolith](), [organizational-structure](), [scalability](), [software-architecture]() ### 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 ## Modularizing Rails Monoliths One Bite at a Time DevFeed: [Modularizing Rails Monoliths One Bite at a Time]() Original publisher: [Read original article]() Author: Doximity Published: 2023-12-05T13:00:00Z Content type: article Language: en Sources: [Doximity]() Topics: [Ruby on Rails](), [Refactoring](), [modules](), [Architecture & Design](), [Microservices]() Tags: [microservices](), [modular-monolith](), [modularization](), [modules](), [rails](), [refactoring](), [ruby](), [ruby-on-rails]() ### AI overview The article describes using a phased refactoring approach and the packwerk gem to modularize growing Rails monoliths into modules with enforced boundaries. It presents the modular monolith as a lower-complexity alternative to adopting microservices and references Doximity's experience. ### Source excerpt As Rails monoliths grow, coupling becomes increasingly difficult to manage. Developers often reach for microservices to help simplify things, but instead find higher complexity. The Modular Monolith approach is a proven, lightweight alternative that offers the benefits of enforced boundaries without being cumbersome. I spoke at the 2023 Rocky Mountain Ruby conference on how teams can use a phased approach to refactoring toward this style using the packwerk gem. At Doximity, we've used this gem and a phased approach to break some of our most critical rails applications into modules that are easier for our teams to work with. In November, 2023, I also chatted with Elise Shaffer on The Ruby on Rails Podcast about our experience with application modularization at Doximity. Be sure to follow @doximity_tech if you'd like to be notified about new blog posts. ## Resource Bundle Look-ups in Modular Java Applications DevFeed: [Resource Bundle Look-ups in Modular Java Applications]() Original publisher: [Read original article]() Published: 2021-08-29T16:30:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [Java](), [App](), [Development]() Tags: [java](), [modular-monolith](), [module](), [modules]() ### AI overview This article explains how to use Java ResourceBundle providers to manage locale-specific error-message resources across named modules in a multi-module application. It describes a design in which individual modules contribute their own bundles while a central component displays or logs messages without knowing the specific modules. ### Source excerpt Table of Contents The ResourceBundleProvider Interface Resource Bundle Providers Running on the Classpath Discussion and Wrap-Up The ResourceBundle class is Java's workhorse for managing and retrieving locale specific resources, such as error messages of internationalized applications. With the advent of the module system in Java 9, specifics around discovering and loading resource bundles have changed quite a bit, in particular when it comes to retrieving resource bundles across the boundaries of named modules. In this blog post I'd like to discuss how resource bundles can be used in a multi-module application (i.e. a "modular monolith") for internationalizing error messages. The following requirements should be satisified: