Designing Microservices

The biggest mistake in microservices is building a "Distributed Monolith." To avoid this, you must find the Bounded Contexts—the logical boundaries where a service can live independently.

1. Domain Driven Design (DDD)

We use DDD to identify "Subdomains." For example, User Management, Order Processing, and Payment are all separate bounded contexts. They should have their own databases and their own release cycles.

2. Shared Databases are Prohibited

Architectural Rule #1: **Never let two microservices share a database schema**. If Service A and Service B both read from the same table, you cannot change the schema without breaking both. This creates tight coupling and defeats the purpose of microservices.

4. Interview Mastery

Q: "How do you handle 'Transactions' across multiple microservices?"

Architect Answer: "We use the **Saga Pattern**. Since we can't use a single SQL transaction across networks, a Saga performs a series of local transactions. If one step fails (e.g., payment failed), the Saga executes **Compensating Transactions** to undo the previous steps (e.g., restock the inventory). We never aim for 'Atomic' consistency; we aim for 'Eventual' consistency."