Monolith vs microservices
A monolith is one deployable application. A microservice architecture splits a system into small services, each owning one business capability and its own database, and each deployed independently.
Benefits: independent deploys and scaling, team autonomy, fault isolation, and freedom to pick technology per service.
Costs: network calls fail, data consistency gets harder, and you need service discovery, tracing, CI/CD for many services, and real operations maturity.
Practical advice: start with a modular monolith with clear module boundaries (for example using Spring Modulith). Extract a service when a module has a real reason to stand alone: different scaling needs, release pace or team ownership.
Split by business capability (catalog, orders, payments, notifications), not by technical layer.
Example
A typical learning-platform split
catalog-service courses, lessons, search PostgreSQL
order-service carts, orders, invoices PostgreSQL
payment-service Razorpay or Stripe, refunds PostgreSQL
user-service profiles, enrollments PostgreSQL
notification-svc email, SMS, push consumes Kafka events
api-gateway routing, token checks, rate limitsCommon mistake
Sharing one database between services. They become coupled through the schema, so you can't change or deploy one without the others.
Under the hood
Conway's law: systems end up mirroring the communication structure of the teams that build them. A distributed monolith (services that must be deployed together, or that share one database) has all the costs of microservices and none of the benefits. If one small team owns everything, microservices rarely pay off.
Check yourself
What's the best first step for a new product with a small team?
How this connects
Part of Crack the Java interview, Microservices and production.
Was this lesson helpful?
Finished reading? Mark it complete to track your progress.