Task system in microservices (Spring Boot)

#Context

A personal project to move past theory and feel firsthand what microservice architecture actually costs: service-to-service communication, responsibility boundaries and the real price of distributing something that would fit in a monolith. The idea was a task system where the user creates tasks and gets notified about progress and deadlines.

#What the product does

Creates and manages tasks with an associated deadline.
Notifies the user about progress and approaching deadlines.
Splits those responsibilities across three independent services that talk to each other.

#Architecture

The three microservices

#Technical decisions

Why split into three services something that would fit in a monolith?

Precisely because it would fit in a monolith. The goal was to learn: only by actually splitting it do you feel the cost of communication, versioning and coordination between services. For a real product this size, the monolith would be the right call — and reaching that conclusion is part of the outcome.

Why Spring Boot for the experiment?

I wanted to exercise the Java ecosystem in a distributed backend, which is the standard across much of the enterprise market. The trade-off was more ceremony and configuration than I'd have in Node, in exchange for learning the stack where it's most used.

How do the services communicate?

Via REST calls between them, with the main service orchestrating the flow. It's the most direct, readable option for the scope; a natural next step would be swapping part of it for async messaging once the temporal coupling started to hurt.

#What went wrong

The lesson was honest and useful: microservices have a cost before they have a benefit. For the size of the problem, three services added network and deploy complexity a monolith wouldn't. The project did its job of teaching me exactly when not to use this architecture — which now saves me from applying it out of fashion in real work.

#Outcome

Three working microservices, public on GitHub: main, tasks and notification.
A concrete basis for deciding, in real projects, between a monolith and distributed services — on judgment, not hype.