Microservices or Monolith?

Let me get one thing out of the way: both approaches work. The question isn't which one is "correct" — it's which one fits your team better, and whether you're ready to pay for the overhead each of them drags along.

This is a cheat sheet, a continuation of the micro-article series. I'll leave the details and the reasoning for the next texts.

Monolithic architecture

Pros

1. Simple to develop and test.
2. High performance thanks to the absence of inter-process communication.
3. Easy to manage — one deployment for all components.

Cons

1. Hard to scale the entire application.
2. Updating one part requires restarting the whole application.
3. Harder to maintain and evolve as the application grows.
4. A bug in one module can take down the entire application.

Microservices architecture

Pros

1. Easy to scale individual services.
2. Improved resilience: a failure in one service doesn't knock out the whole system.
3. Development flexibility — different teams can work on different services in parallel.
4. You can update individual services without restarting the whole application.

Cons

1. Hard to manage a swarm of independent services.
2. You have to set up the communication between services.
3. Increased overhead from inter-service communication.

What's better for a small company?

It all comes down to needs and resources:

• A monolithic architecture can be preferable for startups and small projects, since it's simpler to develop and manage — especially when the team is small.
• A microservices architecture can pay off for companies planning rapid growth and scaling, running distributed teams, or wanting to use different technologies for different parts of the system.

What level of engineers each approach needs

What to expect when you bring an engineer of a given level onto the team.

Monolithic architecture

• Junior. Basic understanding of the application's structure, comfortable with simple tasks.
• Middle. Deep grasp of architectural patterns and techniques for optimizing a monolith.
• Senior. Able to design and optimize monolithic systems, audit existing ones, and think strategically.

Microservices architecture

• Junior. Understands the basic concepts of microservices and communication over APIs.
• Middle. Experience developing and managing multiple microservices, familiar with deployment orchestration tools (Kubernetes, for example).
• Senior. Able to design complex microservice systems, experienced in scaling and securing them, capable of strategic planning.

A checklist for picking an approach for your company

1. Team size and resources:

• Small team and limited resources — Monolith.
• Large or distributed team — Microservices.

2. Growth and scaling plans

• Limited growth — Monolith.
• Rapid growth and scaling — Microservices.

3. Performance requirements

• High performance with minimal overhead — Monolith.
• Flexible, scalable performance — Microservices.

4. Team expertise level

• Less experience managing complex systems — Monolith.
• Strong expertise and hands-on experience with distributed systems — Microservices.

5. Update frequency

• Rare updates, big releases — Monolith.
• Frequent updates and fast releases — Microservices.

6. Infrastructure capabilities

• Limited infrastructure capabilities — Monolith.
• Mature infrastructure with orchestration support — Microservices.

Takeaway

A monolith is simpler to develop and manage — exactly what small companies and resource-constrained startups need. Microservices give you flexibility and scalability — the choice of large, fast-growing teams that care about performance and frequent releases. There's no universal answer: start from the business's needs, the team's experience, and what you actually have on hand. In the next article I'll share my own experience — why I ended up choosing microservices over a monolith. Hope you'll find it interesting.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP