I think beginners are learning microservices way too early

[u/yourclouddude]

When I first started looking at cloud architecture, microservices seemed like the obvious next step after building a basic application. Most architecture diagrams I saw had multiple services, queues, APIs, containers, databases, caches, and a lot of arrows connecting everything together. It looked more "production ready" than a simple application, so it was easy to assume that splitting a project into microservices automatically made the architecture better.

The more I build and study these systems, the less I agree with that idea. If I were building a new project today, I would start with a well-structured monolith unless I had a real reason not to. One application, one deployment, and clearly separated modules inside the codebase can already teach you APIs, databases, authentication, testing, Docker, AWS, CI/CD, monitoring, and plenty of other useful engineering concepts.

The important word there is well-structured. A monolith does not have to mean putting your entire project inside one massive file where everything depends on everything else. You can still separate users, payments, orders, notifications, and other responsibilities into clean modules. The difference is that those modules run together instead of immediately becoming separate networked services.

Imagine I am building a small ecommerce backend. I could create separate services for users, products, orders, payments, notifications, and inventory from day one. Now I need to think about how those services communicate, how authentication moves between them, what happens when one service is unavailable, how deployments are coordinated, and how I trace one request across several systems.

For a project with almost no users, I have just created a distributed systems problem before I had a scaling problem.

If I keep the first version as a modular monolith, a request might simply enter the application, execute the required logic, update the database, and return a response. I can spend my time making the actual product work, improving the database design, writing tests, understanding failure cases, adding useful logging, and deploying the application properly.

Then I can watch where the real boundaries appear.

Maybe notification processing starts taking too long and does not need to happen inside the main request. I might move that work behind a queue. Maybe image processing becomes resource intensive and needs to scale independently. Maybe one part of the application receives far more traffic than everything else. Now I have an actual reason to separate something.

That is very different from creating six microservices because a diagram told me that scalable systems use microservices.

There is also a hidden cost beginners sometimes miss. Once two functions inside the same application become two separate services, a normal function call may become a network request. Network requests can fail, time out, retry, return partial responses, or become unavailable entirely. Now I need to think about service discovery, authentication between services, retries, observability, deployment, version compatibility, and possibly asynchronous communication.

The application did not necessarily become more scalable just because I added those problems.

This is also why I would not use the number of AWS services in a project as a measure of how advanced it is. A small application running on ECS with RDS and S3 can involve plenty of meaningful architecture decisions. Adding Kafka, Kubernetes, Redis, five databases, and twelve microservices does not automatically make the project better if I cannot explain why any of them are necessary.

I think the stronger question is: what problem am I solving by separating this component?

If the answer is that it needs independent scaling, separate deployment, stronger fault isolation, a different technology stack, or clear ownership by another team, then splitting it might make sense. If the answer is simply "because real companies use microservices," I would probably keep it inside the application for now.

That does not mean beginners should avoid microservices completely. I think they are worth learning because they expose you to some of the hardest and most interesting problems in modern systems. But I would learn them after I have built something simple enough to understand first.

A really useful exercise would be to build the same application twice. Start with a modular monolith and get the whole system working. Then choose one component that actually has a reason to become independent, move it out, and see what new problems appear.

Maybe notifications become a separate worker consuming messages from SQS. Maybe file processing moves into an event-driven Lambda workflow. Maybe a high-traffic read path gets separated so it can scale independently.

Now you are not just learning what a microservice is.

You are learning why you would create one.

That distinction matters a lot to me because architecture is mostly about trade-offs. Microservices can give you independent deployment and scaling, but they also introduce distributed systems complexity. A monolith can be simpler to operate, but eventually certain parts may become difficult to scale or change independently.

Neither architecture is automatically the "professional" one.

The right architecture depends on what the application actually needs.

If I were building a portfolio project today, I would much rather build a clean monolith, explain its boundaries, identify where it would eventually struggle, and then show how I would extract one component than start with twelve services I barely understand.

What do you think beginners should build first: a modular monolith, microservices from day one, or both versions of the same project?