Microservices Basics in System Architecture

Microservices Architecture: Decentralized Scaling In a Monolithic Architecture , all business logic, data access, and UI components exist within a single, unified codebase and process. As the team and traffic grow, this leads to a "Big Ball of Mud"—where a bug in a minor feature can crash the entire system. Microservices break this monolith into a collection of small, autonomous, loosely coupled services. Each service owns its specific business domain, its own data store, and its own deployment pipeline. 1. What are Microservices? Microservices are modular building blocks that communicate over a network, typically via lightweight protocols like REST, gRPC, or asynchronous message queues. Autonomy: Each service can be developed, deployed, and scaled independently by a dedicated small team. Polyglot Persistence: You are not locked into one database. A user-profile service might use PostgreSQL (relational), while a real-time feed service uses Redis (key-value). Fault Isolation: If the "Notification Service" fails, the "Ordering Service" remains fully functional, preserving core revenue-generating operations. 2. API Gateway: The Unified Entrance In a system with hundreds of microservices, you cannot expose them all directly to the public internet. It would be a security and maintenance nightmare. The API Gateway acts as a reverse proxy, sitting at the edge of your infrastructure. It is the single point of entry for all client requests (Web/Mobile). Request Routing: The gateway maps external URL paths (e.g., /api/orders ) to the internal IP addresses of the corresponding microservice. Cross-Cutting Concerns: Instead of each service writing its own authentication and rate-limiting code, the gateway handles these tasks globally for all incoming traffic. 3. Service Discovery: The Infrastructure Phonebook In a dynamic microservices environment, containers are constantly spinning up and down. You cannot "hard-code" the IP addresses of your services because those IPs change every time a container restarts. Service Discovery is the mechanism that allows services to find one another. The Registry: An automated database (like HashiCorp Consul or Netflix Eureka) stores the current location of every active service instance. The Flow: When a service (e.g., "Order Service") needs to talk to the "Inventory Service," it queries the Service Registry: "Where is the Inventory Service?" The Registry returns a list of healthy, active IP addresses. The Order Service uses this data to establish a direct connection. 4. Service Mesh: Managing the Network Fabric As the number of microservices reaches the hundreds, managing network calls—retries, timeouts, encryption (mTLS), and observability—becomes impossible to do manually inside every service codebase. A Service Mesh is a dedicated infrastructure layer that handles service-to-service communication transparently, typically using a sidecar proxy (like Envoy). The Sidecar Pattern: Every microservice has a small "sidecar" container running alongside it. All network traffic in and out of the service passes through this sidecar. Mesh Capabilities: Traffic Shifting: Rolling out new features by sending 1% of traffic to the new version. mTLS: Automatically encrypting all inter-service traffic without the application developers needing to write a single line of security code. Observability: Centralized logging and tracing showing exactly how traffic flows through the entire mesh. Microservices Architecture Reference Matrix Concept Primary Operational Mandate Key Tooling Microservices Independent business logic and deployment. Docker, Kubernetes. API Gateway Edge security and request routing. Kong, AWS API Gateway, NGINX. Service Discovery Finding dynamic service instances. Consul, Eureka, CoreDNS. Service Mesh Transparent inter-service network control. Istio, Linkerd.