Splitting ShopEase into Services

Find the Business Capabilities

We split by business capability (what the business does), not by technical layer. Good questions: Which data changes together? Which team owns it? What needs to scale or release on its own?

Service	Owns (entities)	Main APIs	Port
product-service	`Product`, `Category`	list/search products, get product, update stock	8081
order-service	`Order`, `OrderItem`	place order, get order, order history	8082
user-service	`User`, `CartItem`	register, profile, cart	8083
payment-service	`Payment`	charge, refund, payment status	8084

ShopEase Architecture

React web / Android app
                                 |
                                 v
                    +------------------------+
                    |   API Gateway  :8080   |   (medium level)
                    +------------------------+
                 /        |            |          \
                v         v            v           v
       +-----------+ +-----------+ +-----------+ +-------------+
       | product   | |  order    | |  user     | |  payment    |
       | service   | |  service  | |  service  | |  service    |
       |  :8081    | |  :8082    | |  :8083    | |  :8084      |
       +-----+-----+ +-----+-----+ +-----+-----+ +------+------+
             |             |             |              |
        product_db     order_db       user_db      payment_db
        (MySQL)       (PostgreSQL)    (MySQL)      (PostgreSQL)

   order-service --REST--> product-service   (price + stock check)
   order-service --REST--> payment-service   (charge)
   order-service --event-> "OrderPlaced"      (Kafka, medium level)

What Changes From the Monolith

In the monolith	In microservices
`Order` has a JPA `@ManyToOne Product product`	`OrderItem` stores `productId`, `productName` and `unitPrice` (a copy)
`orderService.place()` calls `productService.reduceStock()`	order-service sends an HTTP request to product-service
One `@Transactional` covers order + stock + payment	Each service commits its own transaction; failures are handled with compensations
SQL join orders with products	Combine data in code or keep a local copy

Note: Notice that OrderItem keeps the price at the time of purchase. That copy is correct business data, not duplication: if the product price changes tomorrow, old orders must not change.

Practice

Exercise: ShopEase wants to add product reviews and ratings. Should reviews go into product-service or a new review-service? Give two reasons for your choice.

Show answer

A new review-service is a good choice:
1. Different load: reviews are written/read by millions of users and can
   grow huge; product data is small and changes rarely.
2. Different team and release cycle: moderation rules and spam filters
   change often and should not force product-service releases.
3. Failure isolation: if reviews are down, product pages still load
   (just without the reviews block).
(Keeping it inside product-service is also fine while the team is small;
 the important part is a clear module boundary that can be extracted later.)