Microservices with ASP.NET Core — Introduction

Introduction

ShopNest at enterprise scale may split into Product, Order, and User services — this honest intro covers when microservices help vs when a modular monolith is smarter for Indian startup teams.

After this article you will

• Compare monolith vs microservices trade-offs
• Design single-responsibility services
• Understand sync HTTP vs async messaging
• Use API Gateway and Docker Compose locally
• Wire three ShopNest services communicating

Prerequisites

• Article 50 — AutoMapper
• ShopNest API, EF Core, and DI from prior modules

Concept deep-dive

When NOT: team < 5, unclear boundaries, no DevOps — start modular monolith, extract services later.

# docker-compose.yml (simplified)
services:
  product-api:
    build: ./ShopNest.Products
    ports: ["5001:8080"]
  order-api:
    build: ./ShopNest.Orders
    ports: ["5002:8080"]
  gateway:
    build: ./ShopNest.Gateway
    ports: ["5000:8080"]

Order service calls Product service HTTP GET /api/products/{id} or consumes ProductUpdated events (Article 52).

Hands-on — ShopNest E-Commerce Platform (Orders, Products, Users)

1. Three minimal API projects + YARP gateway.
2. Order creation validates product via HTTP client to Product service.
3. Shared correlation ID header across calls.
4. docker-compose up — demo end-to-end.

Common errors & best practices

• Distributed monolith — services tightly coupled synchronous chains.
• No API versioning between services — breaking changes cascade.

Interview questions

Q: When microservices?
A: Clear bounded contexts, independent scale, large teams — not for day-one MVPs.

Q: API Gateway?
A: Single entry for clients — routes to internal services, handles cross-cutting auth.

Summary

• Microservices trade operational cost for flexibility
• ShopNest split: Products, Orders, Users bounded contexts
• Docker Compose enables local multi-service dev
• Prefer modular monolith until pain justifies split

Previous: AutoMapper
Next: Message Queues with RabbitMQ

FAQ