HLD · Architecture

Microservices Architecture

Decompose a system into independently deployable services with clear boundaries.

1. Monolith vs microservices

Interview line: "Start monolith; extract services when team or scaling pain justifies operational cost."

2. Domain-driven service boundaries

Split by business capability, not technical layer.

• User Service — auth, profiles
• Order Service — checkout, order state
• Payment Service — charges, refunds
• Notification Service — email, push

Bad split: "Database service" + "API service" — creates chatty coupling.

3. Communication patterns

Synchronous (HTTP/gRPC)

Order service calls Payment service and waits. Simple mental model; cascading failures if Payment is down.

Mitigation: Timeouts, retries (idempotent ops only), circuit breaker.

Asynchronous (message queue)

Order placed → event to queue → Notification sends email. Loose coupling; harder to trace.

4. Circuit breaker pattern

States: Closed (normal) → Open (fail fast after N errors) → Half-open (trial request).

Example: Recommendation service down — product page loads without recommendations instead of hanging 30s.

5. Data ownership

Each service owns its database. No shared tables across services — access via API/events only.

Example violation: Order service直接 JOINs users table in Payment DB — creates tight coupling.

6. Distributed tracing & observability

One user request spans 5 services. Use correlation ID (trace ID) in headers; tools: Jaeger, Zipkin, OpenTelemetry.

7. Example: Netflix-style decomposition

1. Monolith streaming app → extract billing, encoding, recommendations
2. Encoding pipeline async via queue (heavy GPU workers)
3. API gateway + BFF (backend-for-frontend) per client (TV vs mobile)
4. Each team owns SLA for their service

8. Challenges (say these in interviews)

• Network latency & partial failures
• Distributed transactions → sagas (see Saga note)
• DevOps overhead: CI/CD per service, K8s, service mesh
• Testing integration across services