Why Modular Monoliths Make Sense Again for Solo Developers Working with AI

Summary

Table of contents

Why modular monoliths are worth revisiting

It is easy to hear “the product may grow” and immediately think “we should start with microservices.” The picture looks clean: each service is deployed separately, teams own their own parts, and busy parts can scale independently.

But the Korean source post frames the problem from a smaller-team reality. When one person, or a very small team, builds and operates a product with AI assistance, the first bottleneck is often not independent scaling. It is the cost of keeping many repositories, deployment pipelines, environment variables, logs, monitoring paths, authentication flows, network failures, and data consistency rules in sync.

A modular monolith keeps one deployment unit while dividing the internal code by domain modules. The point is not to make a “simple monolith” fashionable again. The point is to keep operations simple without letting the codebase become a big ball of mud.

Monolith, modular monolith, and microservices

Monolith

A monolith is one application that runs and deploys as one unit. As Microsoft’s architecture guidance describes, the application usually runs core behavior in one process, and scaling commonly means copying the whole application.

This is convenient at the beginning. Local execution, debugging, and deployment are straightforward. The risk appears later when boundaries disappear: payment code directly changes account data, an order flow edits notification tables, and every change starts to feel dangerous.

Modular monolith

A modular monolith is still deployed as one application, but the code is divided into clear business modules such as account, order, payment, settlement, and notification. The key boundary is internal: modules communicate through public interfaces, application services, or domain events instead of freely importing each other’s internals.

Tools such as Spring Modulith can help document and verify this structure, but the habit matters more than the tool. “It is in the same repository, so any class is fair game” is exactly the habit that turns a modular monolith back into an ordinary monolith.

Microservices / MSA

Microservices split functionality into independently deployable services. As Martin Fowler and James Lewis describe, services are usually organized around business capabilities and often own their own data.

The benefits are real: independent deployment, independent scaling, team ownership, and better failure isolation. The cost is also real: network calls, timeouts, retries, distributed data, observability, deployment automation, and a DevOps culture. Fowler’s “Microservice Prerequisites” is still a useful warning: without those basics, microservices become operational debt instead of architectural improvement.

Comparison table

What changes for solo development with AI

AI-assisted development makes context management more important, not less important. An AI coding agent does not remember the whole company. It works within the current conversation, files, and context window. Anthropic’s documentation also describes context windows as a real limit on what a model can use at once.

If an application is split into many services, every request to the AI may require more surrounding explanation: this service’s API contract, that service’s database schema, message names, deployment environment variables, authentication flow, and recent failure logs. The human spends tokens and attention reassembling the system map.

A modular monolith gives a practical middle ground. Local execution and tests stay inside one application, while module boundaries let the developer say, “only inspect the order module,” or “do not change the public payment interface.” That is a much clearer scope for both the developer and the AI tool.

Practical design criteria

Split modules by business capability, not technical layer

A package layout of controller, service, and repository is not enough. Use business capabilities such as account, order, payment, settlement, and notification as the main boundaries.

Limit direct references between modules

If one module freely calls another module’s internal classes, the boundary is only cosmetic. Define public APIs, application services, or domain events and treat internal types as private.

Think about data ownership early

You do not need a separate database per service on day one. But table ownership should be clear. If the order module directly edits payment tables, extracting payment later becomes much harder.

Keep module-level tests

Tests define what a module accepts and returns. They also reduce regression risk when AI tools modify code inside a module.

Common confusion and failure modes

“If I split folders, is it modular?”

No. Folder names help only when dependency direction and public interfaces are enforced. Without those rules, it is just a reorganized monolith.

“Is microservices architecture always more modern?”

Not automatically. Microservices are operational separation, not just code separation. Timeouts, retries, duplicate messages, tracing, deployment order, and incident response all become part of the architecture.

“Does one database block future extraction?”

Not by itself. Unclear ownership is the real problem. A single database can still support future extraction if each module’s tables and write responsibilities are well understood.

“Does AI make architecture less important?”

The Korean source argues the opposite. AI can write code quickly, but scattered services create scattered context. Clear module boundaries make AI assistance easier to guide and easier to verify.

When to move toward microservices

A modular monolith is not the answer forever. Repeated signals like these can justify extracting one module into a service:

• One function needs independent scaling because traffic is concentrated there.
• Several teams share one deployment unit and release conflicts keep recurring.
• Failure isolation becomes important enough that one feature must not stop the whole system.
• The domain boundary is stable enough to maintain a service contract.
• Monitoring, logging, deployment automation, and incident response are already prepared.

Even then, the safer path is usually to extract one high-value module first, not to rewrite everything as microservices at once. This matches the “Monolith First” perspective: a well-structured monolith can become the starting point for later service extraction.

Conclusion

The practical question is not “monolith or microservices?” It is “what architecture fits my current team size, operating ability, and need for independent scaling?” For multiple teams with strong platform capabilities, microservices can be powerful. For a solo developer or small team building quickly with AI, a modular monolith is often the more realistic starting point.

The Korean source also includes a personal operating lesson: after working with tools such as Claude Code, Codex, and Gemini, the author found that split services often consumed more tokens and attention because the AI had to be reminded of contracts, schemas, events, environment variables, and logs across services. Keeping one deployable application while enforcing module boundaries made the work easier to guide, test, and operate.

References

1. 🔗 Microsoft Learn — Common web application architectures
2. 🔗 AWS — What are Microservices?
3. 🔗 Martin Fowler / James Lewis — Microservices
4. 🔗 Martin Fowler — Monolith First
5. 🔗 Martin Fowler — Microservice Prerequisites
6. 🔗 Spring Modulith Reference
7. 🔗 microservices.io — Monolithic Architecture
8. 🔗 microservices.io — Microservice Architecture
9. 🔗 Kamil Grzybek — Modular Monolith: A Primer
10. 🔗 Anthropic Docs — Context windows