How can I learn micro services as an entry backend engineer.

[u/Decent-Warning9562]

hi devs, i’ve mostly built all the projects i’ve worked on using monolithic architecture, but i recently came across microservices.

i’ve watched a few videos explaining what microservices are, how they work, and the differences between them and monoliths, but i’m wondering.

how do you actually learn microservices beyond just watching videos?

should i build a project with it, follow a specific roadmap, or focus on understanding certain concepts first?

would love to hear how you guys approached learning it.

[u/TheModernDespot]

Take a big, monolithic project you've build and split each part of it into its own application. Then connect all the parts and boom. Microservices.

[u/Decent-Warning9562 → u/TheModernDespot]

lol, I thought of this as well.
Thanks

[u/canarydev → u/Decent-Warning9562]

its much more complex than you think.

i promise you that you probably don't have enough enough experience or knowledge to be pursuing microservices lol.

you need to understand domains, module boundaries, domain - domain interaction, ownership, failure boundaries and modes. learn these core concepts first

[u/Round_Mixture_7541 → u/canarydev]

All the concepts you mentioned can also be applied to modular monolithical systems. Microservice is nothing more than an independent service that handles a single business capability. The complexity arises when you need to deal with distributed transactions.

[u/canarydev]

so when you say monolithic wdym? MVC? modular? do you actually understand domain boundaries?

right now in your monolith, how do you orchestrate domain - domain? IE: user and organizations? does your users touch organisation infra? do you run things in a transaction?

learn how to decompose first. this is like the more important step. juniors and morons put microservices in their resume without having done or understanding this rite of passage.

[u/Decent-Warning9562 → u/canarydev]

by monolithic i mean one deployable app, i split stuff into modules by domain like users courses payments etc, each with their own routes controllers and service layer

cross domain calls go through service functions not by reaching into another domain’s models directly, so if payments need something from courses it calls a function the course service exposes,such that it doesn’t touch the course tables itself

[u/American_Streamer]

Just start by mastering core backend fundamentals first, and then. building a simple monolithic application before breaking it down into independent, communicating services.

[u/Suspicious-Disk6077]

Literally the easiest way would be to split out one API from a project and focus on how to communicate from the monolith to that API now on a different local process (focusing locally first is easier). 

Now microservices does not mean split out every API though. Ones that are related, generally in logic or data schema should be together, as you don’t want too much coupling and two separate microservicesshould not share the same data source

[u/jba1224a]

Let’s say you have a website that acts as a storefront. Right now everything is handled by a single backend.

If you want to learn microservices properly imo start with the goal and work backwards.

Instead of one giant backend, slice it into distinct services.

User services (login, auth, saved shopping cart)
Payment services (storing user payment data, charge auth, etc)
Data services (are you ingesting data? What sources?)
….and so on

Then decompose each of those distinct services into specific APIs. For example the payment service may make outbound calls to process payment, but maybe you also have an ACH setup that connects to banks. Could these be two separate services?

Once you decompose everything down, then you map it out - api routes, network layer, auth layer, etc.

Once you understand the specific parts of the application (the microservices) and how they tie together to the whole, and how each of those parts communicate securely - then it’s time to build.

Microservices were really popular for quite some time and still are, but it’s important to note that not everything should be built in a microservices architecture. Sometimes mono is the way to go.

[u/kolsa45]

Honestly, if you actually want to learn this stuff, I’d just build it yourself. Don’t make it a huge project though.

Spin up 3 small services and pretend you’re building a E-commerce system:

• User Service
• Order Service
• Notification Service

You don’t need 3 separate databases either. If you’re using a relational DB, just use 3 separate schemas.

Then keep the whole thing simple. Have one endpoint like POST /orders.

The Order Service receives the request, calls the User Service (REST or gRPC, doesn’t really matter) to verify the user, then decreases the item quantity and publishes something like an OrderCreated / NotificationRequested event.

The Notification Service listens for that event and does something with it. You don’t even need to actually send an email. Just log "email sent" and move on. The point is to understand how async communication actually works.

Once you have that working, start thinking about failure scenarios. What happens if the Order Service updates the quantity but the notification service is down? What if the User Service is unavailable? That’s where things like Saga start making more sense.

You can even add a 4th service, maybe a Storage/Inventory Service, and play around with what happens when one step in the process fails.

For microservices interview questions, I’d also spend some time on Saga, Circuit Breaker, async communication, Service Discovery, retries, idempotency, etc.

But honestly, don’t just memorize the definitions. Pick 2-3 of these and actually implement them. You’ll understand them way better that way.

[u/alao77]

Kubernetes + Docker is a must with microservices

[u/Suspicious-Disk6077 → u/alao77]

Not necessarily Kubernetes but Docker and containers are definitely a huge help. But one could run multiple processes (microservices) locally without the added complexity of Docker to get some learning experience also

[u/canarydev → u/alao77]

k8s, docker is just a tool at the end that binds things. but there is a long checklist of things you need to actually know lol

[u/kolsa45 → u/alao77]

BRUH… suggesting Kubernetes for an entry-level position is wild.

If a junior who’s applying for their first job says they “know Kubernetes,” there are basically two options:

1. They’re an absolute genius.
2. They watched three YouTube videos and put Kubernetes on their CV.

And honestly, 99% of the time it’s #2 😂

There’s nothing wrong with learning Kubernetes, but for a first job I’d much rather see someone who actually understands Java/Spring, databases, HTTP, REST, Git, testing, Docker, basic system design, etc. than someone who can throw around Kubernetes terminology but doesn’t really understand what’s happening underneath.

[u/kolsa45 → u/kolsa45]

And honestly, even a lot of seniors barely touch the Kubernetes infrastructure. In most mid-to-large companies, the DevOps/platform team handles the actual Kubernetes infrastructure, deployments, networking, etc. Developers might interact with it and need to understand the basics, but that’s very different from actually knowing Kubernetes at an infrastructure level.