Microservices Architecture — Core Concepts
Interview Relevance: Very High — Understanding how services talk to each other, how clients find them, and how traffic enters the system is fundamental to every large-scale design.
Monolith vs. Microservices
The trade-off:
Monolith: Simple to develop, test, and deploy at small scale
Painful at large scale (tight coupling, team bottlenecks)
Microservices: Complex to operate (networking, discovery, observability)
Essential at FAANG scale (hundreds of services, thousands of engineers)API Gateway
The API Gateway is the single entry point for all client traffic into a microservice system.
What an API Gateway Does
API Gateway Request Flow
API Gateway vs. Load Balancer
| Feature | Load Balancer | API Gateway |
|---|---|---|
| Purpose | Distribute traffic across instances | Smart routing + cross-cutting concerns |
| OSI Layer | L4 (TCP) or L7 (HTTP) | L7 (HTTP/gRPC) |
| Auth | ❌ No | ✅ Yes |
| Rate limiting | ❌ No | ✅ Yes |
| Protocol translation | ❌ No | ✅ Yes (REST↔gRPC) |
| Request transformation | ❌ No | ✅ Yes |
| Routing granularity | By IP/port | By URL path, method, header |
| Examples | AWS NLB, Nginx, HAProxy | Kong, AWS API GW, Apigee, Envoy |
Use both: LB distributes traffic across API Gateway instances. API Gateway then routes to the correct microservice.
Service Discovery
In a dynamic environment, service instances come and go (autoscaling, deployments). Service Discovery solves: "How does Service A find the current IP:port of Service B?"
The Problem
Client-Side vs. Server-Side Discovery
Service Registration & Health Checks
Service Discovery Tools
| Tool | Type | Used By | Notes |
|---|---|---|---|
| Consul | Client-side + Server-side | HashiCorp ecosystem | Health checks, KV store, multi-DC |
| Eureka | Client-side | Netflix / Spring Cloud | Simple, Java-centric |
| etcd | Key-value store | Kubernetes | Kubernetes uses etcd under the hood |
| Kubernetes DNS | Server-side | k8s environments | payment-service.default.svc.cluster.local |
| AWS Cloud Map | Server-side | AWS ECS/EKS | Managed, integrated with ALB |
| Zookeeper | Coordination | Kafka, older systems | More complex, being replaced |
RPC vs. REST
How do microservices talk to each other? Two dominant styles.
REST (Representational State Transfer)
gRPC (Remote Procedure Call)
RPC vs. REST — Full Comparison
| Dimension | REST | gRPC |
|---|---|---|
| Protocol | HTTP/1.1 or HTTP/2 | HTTP/2 only |
| Data format | JSON (text — human readable) | Protobuf (binary — ~5-10x smaller) |
| Contract | OpenAPI/Swagger (optional) | .proto file (mandatory, enforced) |
| Type safety | ❌ Runtime only | ✅ Compile-time (generated clients) |
| Streaming | ❌ Limited (SSE, WebSocket workaround) | ✅ Native (4 streaming modes) |
| Browser support | ✅ Native | ❌ Needs grpc-web proxy |
| Latency | Higher (JSON parsing + headers) | Lower (binary, header compression) |
| Multiplexing | HTTP/1.1: no · HTTP/2: yes | ✅ Always (HTTP/2) |
| Code generation | Optional (Swagger codegen) | ✅ Auto-generated clients in 10+ langs |
| Discoverability | ✅ Self-documenting URLs | ❌ Need proto files + tooling |
| Use case | Public APIs, browsers, mobile | Internal microservice RPC |
When to Use Which
Putting It All Together — Full Microservice Architecture
Key architectural decisions visible here:
| Decision | Choice | Reason |
|---|---|---|
| Client → Gateway | REST/HTTPS | Browsers and mobile apps need standard HTTP |
| Gateway → Services | REST | Simple, compatible with all service types |
| Service → Service | gRPC | Internal: lower latency, typed contracts |
| Async events | Kafka | Decouple Order → Notification, Order → Search |
| Service discovery | k8s DNS / Consul | Dynamic IP resolution for scaling |
| Database per service | Yes | Loose coupling, independent schemas |
Interview Cheat Sheet
One-Line Summaries
API Gateway: Single entry point — auth, rate limiting, routing, protocol translation
Service Discovery: Dynamic registry so services find each other's current IP:port
Client-side SD: Service queries registry, then load-balances itself (Eureka + Ribbon)
Server-side SD: Service calls stable DNS; LB queries registry (k8s, AWS ALB)
REST: HTTP + JSON — universal, human-readable, great for public APIs
gRPC: HTTP/2 + Protobuf — fast, typed, streaming — great for internal RPCs
Service Mesh: Infrastructure layer (Istio/Linkerd) adding mTLS, retries, tracing to all RPCThe Interview Phrase
"Clients hit the API Gateway, which handles authentication via JWT
validation, rate limiting via Redis counters, and routes to the
correct service by URL path. Internal service-to-service calls use
gRPC for lower latency and type safety — the generated proto clients
catch mismatches at compile time. Services register with Consul on
startup; the gateway uses Consul to resolve IPs dynamically so
autoscaling is transparent. Async operations like sending notifications
go through Kafka so the Order Service returns immediately without
waiting for downstream services."Red Flags vs. Green Flags
| 🔴 Red Flag | 🟢 Green Flag |
|---|---|
| Share a database between microservices | Database per service — each owns its data |
| Skip the API Gateway | Always explain auth, rate limiting, and routing at the gateway |
| Use REST for all internal calls | gRPC for internal service-to-service; REST for public APIs |
| Hardcode service IPs in config | Service Discovery (Consul, k8s DNS) for dynamic resolution |
| Synchronous call chains (A→B→C→D) | Async events via Kafka for non-critical paths |
| Ignore the API Gateway as a SPOF | Deploy gateway in HA (multiple AZs, managed service) |
IMPORTANT
Database per service is non-negotiable. If two services share a database, they are not truly independent. A schema change in one breaks the other. Always state this explicitly.
TIP
Mentioning a service mesh (Istio or Linkerd) for features like mutual TLS (mTLS) between services, automatic retries, and distributed tracing is a strong senior signal in system design interviews.