Intro

You’re opening up a restaurant in downtown.

“Where should the table be? Could it be in the kitchen?”

This is probably the most basic thing to consider — the kind of thing so obvious, you almost forget to think about it at all.

Now you’re a developer.

It’s the same kind of question you ask.

“Where do I put this code?”

Thankfully, modern frameworks already have an answer for this.

Today, we will be diving into Spring Boot to better understand microservice architecture.

Index

1. Layers
2. Services
3. Monolithic Architecture vs Microservice Architecture
4. Why Microservice Architecture
5. Coming Up Next!

Layers

If you’re familiar with Photoshop or Illustrator, there’s a high chance you already know what a layer is.

Is it the same concept in Spring Boot?

Probably not, but this gets you a head start.

In Photoshop, layers are about putting something on top of something else.

However, in Spring Boot, layers are about flow.

In the world of Spring Boot, the architecture is designed to make data access simpler and more structured.

Controller → Service → Persistence → Database

Controller Layer 📣

The layer that receives user requests and returns responses.

Service Layer 🧮

The layer that handles business logic.

Persistence Layer 🔎

The layer that communicates directly with the database to store and retrieve data.

Database 🗃️

The place where the actual data is stored.

When I first began learning programming, everything felt impossibly complicated.
Every concept sounded bigger than me, and I thought I had to understand every detail perfectly before I could move forward.

But somewhere along the way, I realized something comforting.

Most things in programming are not sacred rules carved into stone.
They are simply ideas people created after years of trial and error — little agreements designed to make life easier, systems cleaner, and chaos quieter.

Layers are one of those ideas.

Think about a restaurant.

There’s no law stopping someone from placing dining tables right in the middle of the kitchen.
People could eat beside the stove while chefs rush around carrying hot plates and shouting orders.

But it would feel messy.
Heavy.
Uncomfortable.

Service

A Service is an object that handles business logic and coordinates how data should be retrieved or stored in order to perform a specific business function.

In modern application architecture, controllers usually do not contain most of the business logic anymore.

Of course, technically, you can put everything inside the controller.
(I still do that sometimes in small personal projects when I’m feeling lazy.)

But as applications grow, separating responsibilities makes the code easier to read, maintain, and expand.

Monolithic vs Microservice

Let’s use an online shopping mall as an example.

Monolithic Architecture

A monolithic architecture is a structure where every feature exists inside a single Spring Boot application.

Shopping Mall App
├─ User
├─ Product
├─ Order
├─ Payment
└─ Delivery
        ↓
   One Database

For example, when a user places an order:

Order Controller
 → Order Service
 → Product Repository
 → Payment Service
 → Delivery Service
 → Database

=> The user system, product system, order system, payment system, and delivery system are all running together inside a single server and application.

Microservice Architecture

In a microservices architecture, servers are separated by feature or responsibility.

Each service usually owns and manages its own database.

User Service      → User DB
Product Service   → Product DB
Order Service     → Order DB
Payment Service   → Payment DB
Delivery Service  → Delivery DB

For example, when a user places an order:

Order Service
 → Requests stock validation from Product Service
 → Requests payment processing from Payment Service
 → Requests delivery creation from Delivery Service

=> Instead of everything living inside one giant application, the order, payment, and delivery systems are separated into independent services that communicate through APIs or messaging systems.

If you want to learn more about how each service communicates with the others in microservice architecture, you can check out my blog post about it below.

How Microservices Communicate in Spring Boot - Ria Choi • May 18th, 2026

Why Microservice Architecture?

Congratulations! You’ve already mastered microservice architecture!

Now, if microservices look cleaner and more organized, shouldn’t we always use them?

The answer is — not necessarily.

Before deciding when to use microservices, we first have to understand why someone invented this architecture in the first place.

Why Do We Use Microservices?

There are many advantages to microservices, but one of the biggest reasons is traffic flexibility.

Imagine your restaurant normally receives only one or two customers every hour.

A quiet little place.
Small kitchen.
Small staff.
Everything works perfectly fine.

But then — suddenly — something unexpected happens.

The small ice cream stand you placed outside during summer becomes wildly popular.

People begin lining up outside the restaurant just for ice cream.

Now here comes the important question:

Should you rebuild and enlarge the entire restaurant just because one seasonal feature became popular?

Probably not.

That would be incredibly inefficient.

So instead, you make a smaller, smarter decision.

You hire one more employee dedicated only to handling ice cream orders.

The restaurant still works together as one business,
but the ice cream flow becomes separated and independently scalable.

That is the core philosophy behind microservices.

Now let’s translate this idea into a real shopping mall system.

Normally, traffic across the platform may feel relatively balanced.

But during major events or sales seasons, things change dramatically:

• Product page traffic explodes
• Cart requests rapidly increase
• Payment traffic spikes heavily
• Delivery tracking traffic stays relatively small

In a monolithic architecture, you usually have to scale the entire application together.

Which means even if only the payment system is overloaded, you may still need to scale:

• User system
• Product system
• Delivery system
• Everything else

Even the parts barely receiving traffic.

But in a microservices architecture, you can scale only the services under pressure.

Product Service   → 5 Servers
Order Service     → 3 Servers
Payment Service   → 4 Servers
Delivery Service  → 1 Server

Instead of expanding the whole building,
you expand only the crowded room.

That is why microservices became important.

Microservices allow systems to independently scale only the features receiving heavy traffic, making server resources far more efficient.

Of course, this flexibility comes with trade-offs.

More servers.
More network communication.
More operational complexity.

Which is why microservices are not automatically “better.”

Sometimes a simple monolithic application is exactly the right choice.

Architecture is rarely about choosing the most impressive solution.
It is about choosing the solution that fits the size and shape of your problem.

What’s Next?

In the next post, we’ll explore Spring Cloud and learn how large-scale microservice systems communicate, scale, and manage complexity together.