Microservices Architecture: Concepts, Patterns, and Interview Notes

This note condenses my microservices architecture study material into a single reference: what microservices are, when to use them, how to design and operate them, and how to answer common interview questions.

1. What is a microservice?

A microservice is a small, autonomous service that focuses on a single business capability and communicates with other services over a network API (often REST/gRPC or messaging).

Core ideas:

Each service has one main responsibility (Single Responsibility Principle).
Services are loosely coupled and independently deployable.
Each service owns its data (its own database or schema).
Services communicate via well-defined, versioned APIs.

2. Key characteristics

Single responsibility – Each service is built around one business capability (e.g. billing-service, user-service), not generic technical layers.
Decentralized data – Each microservice has its own data store. No shared monolithic database. This enforces loose coupling and allows different storage technologies.
Independent deployability – You can deploy one service without redeploying the entire system.
Inter-service communication – Lightweight protocols:
- Synchronous: HTTP/REST, gRPC.
- Asynchronous: message brokers (Kafka, RabbitMQ, SQS) and events.
Fault isolation – A failing service should not crash the whole system. Use timeouts, retries, circuit breakers, bulkheads, and graceful degradation.
Polyglot tech – Each team can choose the language/runtime and database that best fits their service.

3. Advantages and disadvantages

Advantages

Scalability: Scale hot services independently (e.g. scale checkout-service without scaling everything else).
Team autonomy: Different teams can own different services and release on their own schedule.
Resilience: Failures are contained; the system can degrade instead of completely going down.
Technology freedom: Polyglot programming and polyglot persistence.
Maintainability: Each codebase is smaller and easier to understand.

Disadvantages

Operational complexity: Many small services mean more deployments, monitoring, logs, and failure modes.
Distributed data and consistency: Cross-service transactions are hard; you often rely on eventual consistency and patterns like sagas.
Network overhead: More network calls → higher latency and more failure points.
Testing complexity: End-to-end tests and integration tests are harder than testing a single monolith.
Security surface area: Many network endpoints to secure (auth, TLS, rate limiting, input validation).

Rule of thumb: microservices make sense once your organisation and system complexity justify the operational overhead.

4. Core design patterns

Service discovery – Registry (e.g. Consul, Eureka) where services register themselves and look up each other. Supports dynamic scaling and failure recovery.
API gateway – Single entry point for clients:
- Routes requests to internal services.
- Handles auth, rate limiting, logging, request/response shaping.
- Hides internal topology from external clients.
Circuit breaker – Stops calling a failing downstream service once failures cross a threshold; returns fallback responses while it is “open”.
Service mesh – Infrastructure layer (Istio, Linkerd) for:
- mTLS between services.
- Retry/timeout policies.
- Observability (metrics, traces, logs).
- Traffic shaping and canary releases.
Event sourcing – Store changes as an append-only log of events; reconstruct state by replaying events. Useful for auditability and complex workflows.
CQRS (Command Query Responsibility Segregation) – Separate write models (commands) from read models (queries) to optimise for performance and scaling; often combined with events.
Saga pattern – Manage distributed workflows/transactions as a series of local steps with compensating actions:
- Choreography: services emit and react to events.
- Orchestration: central saga orchestrator drives the sequence.

5. Implementation and platform pieces

Implementation typically involves:

Decomposing the monolith
- Identify clear business capabilities and bounded contexts.
- Start with low‑risk/non‑critical modules using the strangler pattern.
Defining APIs and contracts
- REST/gRPC APIs documented with OpenAPI/Protobuf.
- Use contract testing (consumer‑driven contracts) so changes to a service don’t break dependants.
Choosing tech stack per service
- Runtime: Java/Spring Boot, .NET, Go, Node.js, etc.
- Data stores: PostgreSQL, MongoDB, Redis, Cassandra, etc., based on access patterns.
Containerisation and orchestration
- Package each service as a Docker image.
- Deploy and scale with Kubernetes, ECS, AKS, EKS, etc.
Observability and operations
- Logging: centralised (ELK, Loki, Splunk).
- Metrics: Prometheus + Grafana.
- Tracing: Jaeger or Zipkin for distributed traces.
- Dashboards & alerts: for latency, error rates, saturation, SLOs.
Security
- API auth (OAuth2, OIDC, JWT).
- Network policies and mTLS between services.
- Centralised secrets management (Vault, AWS Secrets Manager, K8s secrets).

6. Data and consistency strategies

Cross-service data is where microservices get tricky. Patterns:

Service‑owned data – One service is the source of truth for a business entity. Other services query it or consume its events.
Eventual consistency – Instead of distributed transactions, let services publish events (e.g. “OrderPlaced”) so others update their own state asynchronously.
Sagas – For multi-step operations (e.g. order → payment → inventory → shipping):
- Use a saga to coordinate steps.
- If one step fails, run compensating actions (refund payment, restock inventory).
Idempotent operations – Support safe retries by making operations idempotent (e.g. based on a unique request ID).

For interviews: be ready to discuss why 2PC is usually avoided and how you’d use sagas + events instead.

7. Microservices interview checklist (condensed)

When you see a microservices question, think along these axes:

Architecture basics
- Difference from monoliths and SOA.
- Bounded contexts and domain‑driven design.
Communication
- Sync vs async, when to use REST vs gRPC vs messaging.
- API gateway, service discovery, load balancing.
Reliability
- Circuit breakers, retries with backoff, bulkheads.
- Health checks, graceful degradation, timeouts.
Data and transactions
- Eventual consistency, saga pattern, event sourcing, CQRS.
- Handling distributed transactions without 2PC.
Security and governance
- AuthN/AuthZ, secrets, network policies.
- API versioning, deprecation strategy.
Ops / DevOps
- CI/CD pipelines, blue‑green and canary deployments.
- Centralised logging, metrics, tracing.

Use this as a quick revision sheet alongside the detailed Q&A you already have.

8. When not to use microservices

Microservices are powerful, but they are not a silver bullet. Avoid them when:

Your system and team are small; a well‑structured monolith is simpler and faster to ship.
You don’t yet understand your domain boundaries; you will just create a “distributed monolith”.
You lack DevOps maturity (CI/CD, monitoring, runtime automation) to operate many services safely.

Often the right approach is: start monolith, modularise carefully, then split into microservices as pressure grows.

quyennv.com