System Design - Microservices Architecture & API Design

Microservices architecture structures an application as a collection of loosely coupled, independently deployable services, each responsible for a specific business capability or bounded context.

SRP dictates that each microservice should have one and only one reason to change, meaning it should be responsible for a single, well-defined business capability. This promotes modularity and maintainability.

Independent deployment means that each microservice can be developed, tested, and deployed without affecting or requiring redeployment of other services in the system. This enables faster release cycles and reduces coordination overhead.

Service discovery allows client applications and other services to find the network location (IP address and port) of a service instance. This is crucial in dynamic environments where service instances scale up/down or change locations frequently.

In Client-side discovery, the client queries a service registry (e.g., Eureka, Consul) to get available service instances and then directly calls one. In Server-side discovery, the client makes a request to a router/load balancer (e.g., AWS ELB, Nginx) which queries the service registry and forwards the request to an available service instance.

An API Gateway is a single entry point for all clients into a microservices system. Its primary functions include request routing, authentication/authorization, rate limiting, load balancing, caching, and protocol translation.

Common patterns include synchronous HTTP/REST, synchronous gRPC, and asynchronous message-based communication using message queues (e.g., Kafka, RabbitMQ) or event streams.

RESTful APIs are stateless, use standard HTTP methods (GET, POST, PUT, DELETE), operate on resources identified by URIs, and often return data in JSON or XML format. They emphasize a client-server architecture and uniform interface.