Lecture 162: Differences between monolithic and microservice architectures

If you used streaming sites in the 2010s, it was most likely one big application where the recommendation system was tightly coupled with the player, and that player, in turn, couldn't work without the user system. If the database pauses for a couple of seconds — everything stalls, including the admin panel. That's the monolith — a huge ball of intertwined code that you have to update, scale, and fix as a whole.

Now look at a modern streaming service — the player is its own thing, recommendations are separate, and user profiles might live on a completely different server. Comments system down? No big deal, you can still watch movies. New Year's surge of viewers? Just scale up the video servers without touching anything else. That's microservice architecture — a set of independent components that can cooperate, but also run on their own.

Now let's dive into the specifics of both approaches.

Monoliths

Main characteristics of a monolithic architecture:

1. Centralized single codebase: the whole app is packaged as one "unit", whether that's a JAR or a WAR.
2. Tightly coupled structure: all parts of the app (controllers, services, repositories) are tightly coupled — meaning they're strongly linked to each other.
3. Single deployment: even if you change one line of code, you need to rebuild and restart the entire application.

Advantages of a monolith

• Simple deployment: one artifact = fewer environment configuration headaches.
• Easier debugging: it's simpler to run the whole project locally and step through the system.
• Single codebase: all modules live in one place, and changes are applied centrally.
• Beginner-friendly: for newcomers it's usually easier to understand one unified system than a zoo of microservices.

Drawbacks of a monolith

• Scaling issues: a monolith can typically only be scaled vertically (add more CPU, RAM, etc. to the server), so what do you do if you need to scale just a small part of the app? For example, your server API for image processing is way more popular than the rest of the system. Too bad — you still have to scale the whole monolith.
  • Deployment complexity: it's hard to roll out changes in a monolith. Even a small tweak requires rebuilding the entire app. If something goes wrong during deployment, your whole skyscraper (yeah, remember our skyscraper?) can collapse.
  • Failure blast radius: one failure can take the entire application down. For example, if your payment service has an error, the whole site might become unavailable.

Microservices

We already gave an example of a modern microservice app — the streaming site where modules are independent from each other.

Microservices are independent modules that:

1. Do one specific job.
2. Are developed and deployed autonomously.
3. Communicate with each other via standard network interfaces (for example, REST or messaging through Kafka).

Advantages of microservices

• Independent deployment: you can update, fix, or even change the tech stack of a single microservice without touching the others. That reduces the risk of introducing breaking changes.
• Scalability: you can scale only the microservices that are under load. Is your API for uploading cat pics insanely popular? Just spin up more instances of the image-processing service.
• Fault isolation: the failure of one microservice doesn't drag the whole system down. For example, if your mail service breaks, users can still pay, check order status, and add items to the cart.
• Polyglot tech stack: each microservice can use different programming languages and databases that fit the specific task.
• Team autonomy: microservices let different teams work independently, which is super useful in big companies. Each team can focus on its area and deploy changes on their own.

Drawbacks of microservices

• Increased development complexity: building a distributed system is harder. You need to handle failure scenarios, design service interaction strategies, and often balance between synchronous and asynchronous communication.
• Complex deployment: unlike a monolith, deploying microservices requires coordinating many moving parts. You'll need solid CI/CD, a configuration management system (for example, Spring Cloud Config), and monitoring.
• Network Overhead: microservices exchange data over the network. That adds latency and requires a thoughtful strategy for serialization and deserialization.

Monolith vs microservices — a comparison

When to choose a monolith and when microservices?

When to use a monolith:

1. You're just starting the project and your team is small.
2. You don't need high scalability.
3. You want to move fast and get a product to market quickly.

When to choose microservices:

1. The application has grown big and is getting heavy to add new features.
2. You need to scale specific modules.
3. You have large developer teams working on different parts of the system.
4. You need high fault tolerance.

Pitfalls and common mistakes

Moving from a monolith to microservices is not magic that will fix everything. On the contrary, you can end up with more problems if you approach the architecture incorrectly.

1. Over-splitting: if your microservices are too small, you'll get headaches from network communication and coordination complexity.
2. Distributed monolith antipattern: when microservices still depend heavily on each other, a failure in one block breaks the whole app.
3. Lack of tooling: without monitoring tools (for example, Spring Boot Actuator or Prometheus) you risk losing visibility into the system.
4. Data consistency challenges: maintaining consistency across microservices becomes a challenge, especially with asynchronous communication.

Now you're one step closer to deciding what to build: a "skyscraper" or a "neighborhood with little shops." Microservices are a great choice for complex, scalable systems — but only if you're ready for the challenges.