Monoliths & Microservices

An application is a monolith when its entire code lives in a single codebase — one self-contained, tightly coupled unit. Take a social network like Facebook: user posts, comments, groups, marketplace, ads, photo storage, live streaming, a recommendation engine. In a monolith, every one of those features is coded together in the same repository, tightly coupled, rather than each having its own dedicated service.

The upside is right there: monoliths are simple to build, test, and deploy. There's no overhead of managing infrastructure for many services or wiring up inter-service communication.

Starting monolith, growing into microservices

Teams often start with a monolith intending to break out into microservices later. LinkedIn began as a monolith called "Leo" wired to a handful of databases, then moved to a distributed architecture. Uber started with a single repo holding all its logic — matching drivers and riders, background checks, billing, payments — and hit the classic monolith walls as it grew: scaling pain, tight coupling, redeploying everything for one small change, and the constant risk of a change cascading into unrelated features, forcing heavy regression testing.

The monolith's single virtue is simplicity — one repo to develop, test, deploy, monitor, and manage. But that single box has real costs:

Pick a monolith when the app is genuinely simple and won't need serious expansion soon — a to-do app, a mostly read-only sports news app, an internal tax-calculation tool.

In a microservices architecture, each feature of a large service is deployed separately as a small, loosely coupled service, and these work together to form the whole. It's the direct application of two design principles: single responsibility (each service runs one feature) and separation of concerns (each is isolated from the others).

That separation pays off across the board: cleaner maintenance, easier feature development and testing, and independent deployment of each module. Large projects can hand each service to a dedicated team with minimal friction. Scaling is built in — a service that needs more capacity scales independently without touching the others. And critically, each microservice ideally has its own database, which removes shared single points of failure and bottlenecks.

So there are three ways forward: pick a monolith, pick microservices, or start monolith and later scale out into microservices. Which one depends entirely on the use case — the course's advice is to keep things simple and understand requirements thoroughly before deciding.

Beyond the pro/con lists, two forces tend to drive the real decision.

Fault isolation

With microservices, a glitch is contained. You fix the issue in the one service without scanning the whole codebase to find and repair it — that containment is fault isolation.

Development team autonomy

In a monolith, once the number of developers and teams on one codebase grows past a point, productivity drops. As the codebase grows, compile time and test runtime grow with it — because the entire codebase recompiles after any change, not just your module. Worse:

• Another team's change can directly break your feature, so thorough regression testing is required on every push.
• Everyone may have to stop working while a change goes to production.
• Your change may need approval from other teams sharing the codebase — a bottleneck.

Microservices flip this: dedicated teams own their codebases outright, with full development and deployment autonomy and separate pipelines. If you need to move fast, launch many features, and scale — microservices are a good bet. But that delight comes with cost: distributed logging, monitoring, inter-service communication, service discovery, alerts, tracing, dedicated build/release pipelines, health checks, and often custom tooling written from scratch. There's no perfect solution — only clarity about your use case.

The most instructive trade-off stories are the companies that reversed course.

Segment: monolith → microservices → monolith

Segment, a customer data platform, ingests hundreds of thousands of events per second and routes them to 100+ server-side destinations (APIs and webhooks) via message queues. The journey:

1. The monolith. One API ingested events and pushed them to a single distributed queue, which forwarded payloads to destinations. Failed events were retried — so the one queue filled with both new and retried events, eventually flooding and delaying delivery.
2. The split to microservices. They gave every destination its own microservice with its own queue. A flooded queue no longer hurt other destinations — clean fault isolation, better throughput.
3. The complexity wall. As destinations grew, each service+queue had different throughput and load patterns; no single scaling policy fit. Autoscaling still needed manual per-service CPU/memory tuning. More queues meant more maintenance resources.
4. Back to a monolith. They reverted, combining all the per-destination queues into a single service called Centrifuge, giving up fault isolation to reclaim manageability.

Istio

Istio — the open-source service mesh for connecting, securing, controlling, and observing microservices — itself moved from microservices back to a monolith, saying it let them deliver value and hit their goals. It's cited as an example of when not to do microservices.

The big ball of mud (aka spaghetti code) is code with no definite structure — tightly coupled, hard to maintain, hard to refactor. It's a software-design anti-pattern that shows up when delivery speed is prioritized over code quality, piling up massive technical debt.

Picture an online food-delivery service: taking orders, routing them to restaurants and drivers, payments, memberships, inventory. In spaghetti form, all of it is coded together, tightly coupled — no layers (controller, service, DAO), no SOLID principles, no interfaces, no modular design. Adding a feature means first reverse-engineering the code flow, then changing it and hoping nothing breaks — an endless cycle of bugs spawning bugs, and eventually financial loss.

How code turns to mud

The causes are cultural as much as technical: no time invested in design early on; inexperienced developers with little design knowledge; many devs over years each coding in their own style with no standard structure (this is where frameworks like Spring help enforce consistency); always choosing delivery speed over quality; no team code reviews led by seasoned devs (if it worked, it got merged); and no regular refactoring, quality checks, or test coverage.

The fix the course prescribes: don't stuff everything in one layer — use a layered architecture.

Layered architecture (the "lasagna code") splits code into layers — typically controller, service, and data-access — each with one role, communicating through interfaces to stay loosely coupled. The controller handles requests, the service layer runs business logic, the DAO talks to the database. Each layer does its job without worrying about the others; it's the separation of concerns principle in practice. A change in one layer barely touches the rest, which keeps the code maintainable, testable, and extendable. In Java Spring enterprise projects, this is the default pattern.

But layers aren't full isolation. Business features cross-communicate, and in complex projects that cross-talk can turn the code back into a big ball of mud. The escape hatches: move to microservices, or implement a modular monolith. The course also lists non-structural safeguards — seasoned-dev code reviews as a rule, educating juniors on design, practicing domain-driven development, and fixing root causes instead of duct-taping bugs.

A modular monolith is a monolith organized into loosely coupled modules split by business feature, each with its own layers, rather than everything coded together. It sits squarely between the monolith and microservices. If your only reason to adopt microservices is to escape the big ball of mud, this gets you most of the benefit without the distributed-systems overhead.

Modules are drawn along business functionality — inventory in one module, orders in another, payments in another — and they can even connect to different databases rather than sharing the single one a classic monolith uses. The payoff mirrors microservices: code reusability, easier maintenance and extension, better comprehension, observability, lower complexity, and easier testing.

Modularity and domain-driven design

The modular monolith is an implementation of domain-driven design (DDD) — structuring code to align with the business domain. In enterprise projects, domain experts and technical staff model the system together, defining bounded contexts (logical boundaries in a domain with consistent rules — e.g. inventory management is one bounded context, user management another) and converting those contexts into modules. Once built, modules have dependencies on each other — inventory talks to orders, orders talk to payment — which raises the question of how they communicate.

Modules in a modular monolith communicate one of two ways.

Synchronous — through interfaces

A module calls another only through the interface that module exposes, with no knowledge of its implementation. The interface is the entry point, so a module can swap its implementation anytime without breaking callers — loosely coupled by design. (This is also how hexagonal architecture, coming next, does synchronous communication.)

Asynchronous — through an event bus

Async communication is event-based, via an in-memory event bus or a message broker like Kafka. A module publishes events to the bus; other modules subscribed to it read those events. The bus is a central collection point for events across the app, letting modules interact with no direct coupling between them. Guava's EventBus is one example. This is the publish-subscribe pattern.

Hexagonal architecture — aka Ports and Adapters — keeps business logic isolated at the center and pushes all input/output to the edges. It's one way to implement a modular monolith's synchronous communication. Three components:

• Domain — the business logic, sitting at the core; external entities never touch it directly.
• Ports — interfaces/APIs; all input enters through a port.
• Adapters — the implementations of those ports; they convert data from a port into a form the business logic can process.

The hexagon shape means nothing — it's just a visual convention. The name comes by analogy to computer ports (the interface to external devices) and adapters (which convert the port's signals for the chips inside).

Why it beats spreading logic across layers

In plain layered architecture, business logic tends to leak across layers — even into the UI and database stored procedures — making things tightly coupled and hard to test or refactor. Hexagonal keeps all business logic at the core, so a change to it doesn't force refactoring every layer. It still has controller/service/DAO pieces, but organizes them under three high-level layers: application (UI, REST controllers), domain (the model plus the port interfaces), and infrastructure (database, messaging server, and the adapters implementing the ports). Ports/adapters handling incoming traffic are inbound; those handling outgoing traffic to infrastructure are outbound.

Upsides: business logic can be unit-tested in isolation (no need for integration tests or cloud deploys just to test logic — integration tests are better spent on the surrounding layers), and the code stays loosely coupled, extendable, and therefore scalable.

The asynchronous, event-based module communication above rests on a lower-level distinction. Modern frameworks like NodeJS, Play, Tornado, and Akka gained popularity over traditional tech (Java, PHP) for real reasons — starting here.

Event-driven architecture (also called reactive or non-blocking) is built to process asynchronous streams of events — the system continually monitors the stream and reacts. The application becomes inherently asynchronous.

At the service level

Non-blocking technologies — NodeJS, and Java-ecosystem frameworks like Play, Akka, and Spring Reactor — let a service handle a large number of concurrent connections with minimal resources. They're built to run on a cluster and handle large-scale concurrency without the developer wrestling with threads, locks, or out-of-memory issues from high IO. Doing reactive work with traditional thread-based frameworks is painful precisely because of shared mutable state and locks. NodeJS is single-threaded and non-blocking with an event-loop architecture, ideal for IO-intensive work — but a poor fit for CPU-intensive tasks like graphics rendering or ML. Every tech has its use case; non-blocking doesn't make traditional tech obsolete.

At the system level

For streams across many services — changing stock prices, e-commerce transaction events, changing game states — an external message broker (like Kafka) connects the services and routes events between them. In the vocabulary of event-driven systems: modules that publish events are publishers/producers, modules that consume them are consumers, and the broker in the middle is the event router. If you split modules into microservices, users become the event producers and the microservices become the event consumers, with all events flowing through the router.

Why it's worth it

Loose coupling. Say a customer joins a group when they place an order. If services were tightly coupled and the membership service were momentarily down, the whole order flow would fail. With event-driven design, the broker persists the membership events while that service is down; when it recovers, it pulls and processes them — so the business doesn't lose the customer. Parallel processing. Because communication is async through queues, services run their work in parallel without waiting on each other, and if one goes down mid-task, its events sit safely in the queue without affecting the rest.

The lessons cite several external links. Below are the ones that resolve live today, grouped by topic. Several other cited links — a LinkedIn scaling article, an Uber scaling write-up, a Node.js event-loop guide, and a Stack Exchange performance page — returned errors or 404s and are omitted.

Real-world monolith ↔ microservices journeys

Structure & communication patterns