Building 18 Microservices with Spring Cloud: What I Learned from Procraftor

Procraftor started as a monolith. When I hit the point where order processing, payments, and chat notifications all needed to scale independently, I rebuilt it as 18+ Spring Cloud microservices. Here is what that process actually looks like.

Service boundaries matter more than service count

The hard part is not splitting code into services — it is deciding where the boundaries go. Each service in Procraftor maps to a bounded context: user, project, inventory, order, payment, notification, task, media, chat, report, review, search, booking, invoice. If two things change for the same business reason, they belong in the same service.

Infrastructure you need from day one

• Service discovery (Eureka) — services register and find each other without hardcoded URLs
• API Gateway (Spring Cloud Gateway) — single entry point, routing, rate limiting via Redis
• Circuit breakers (Resilience4j) — fallback strategies prevent cascade failures
• Shared DTO library (common-core) — keeps service contracts in sync without tight coupling

Deployment is the real challenge

Building microservices is one thing; running them is another. Each service has its own PostgreSQL schema, Flyway migrations, Actuator health checks, and Swagger docs. Docker Compose works for development; Helm charts and Kubernetes handle production. Without good deployment infrastructure, microservices become micro-problems.

When to stay monolithic

Not everything needs microservices. My other products — CRMCup, PharmacyHub, AscendLMS — run as modular monoliths with JHipster. They are simpler to deploy and debug. I reached for microservices in Procraftor because the marketplace domain genuinely needed independent scaling per service.