Topic 1: Introduction to Microservices Architecture

🚀 TL;DR

• Microservices break large applications into smaller independent services.
• Each service handles one business capability.
• Services communicate over the network.
• Each service can be developed, deployed, scaled, and maintained independently.
• Widely used by companies like Netflix, Amazon, Uber, and Spotify.

📘 Theory & Internals

What is Microservices?

Microservices is an architectural style in which an application is divided into multiple small, independent services.

Each service:

• Has its own responsibility
• Has its own codebase
• Has its own deployment pipeline
• Has its own database
• Can be independently scaled

Instead of one large application, we build multiple smaller applications that work together.

Traditional Monolithic Architecture

A monolithic application contains:

UI
Business Logic
Database Access
Security
Reporting
Payments
Notifications

All packaged into:

application.jar

Any code change requires:

Build Entire Application
Test Entire Application
Deploy Entire Application

Problems:

• Slow deployments
• Difficult scaling
• Technology lock-in
• High coupling
• Large codebase

Microservices Architecture

Instead of:

One Large Application

We create:

User Service

Product Service

Order Service

Payment Service

Inventory Service

Notification Service

Each service runs independently.

User Service      -> Port 8081

Product Service   -> Port 8082

Order Service     -> Port 8083

Payment Service   -> Port 8084

Internal Working

When a customer places an order:

Client
   |
   V
API Gateway
   |
   V
Order Service
   |
   +-----> Product Service
   |
   +-----> Inventory Service
   |
   +-----> Payment Service
   |
   +-----> Notification Service

Each service performs a specific task.

Core Principles

Single Responsibility

One service = One business capability.

Example:

User Service

Handles:

Registration
Login
Profile Management

Not:

Payments
Orders
Notifications

Independent Deployment

Payment service can be deployed without touching:

Order Service
User Service
Inventory Service

Independent Scaling

Suppose:

Payment Requests = 50,000/minute
Order Requests = 5,000/minute

Scale only:

Payment Service

This saves infrastructure cost.

Why Companies Adopt Microservices

Faster Development

Different teams work independently.

Team A -> User Service

Team B -> Product Service

Team C -> Payment Service

Faster Deployments

Deploy only changed service.

Better Fault Isolation

If Notification Service crashes:

Orders Continue
Payments Continue
Users Continue

Only notifications are affected.

Technology Flexibility

Example:

User Service -> Java

Recommendation Service -> Python

Analytics Service -> Go

Microservices Design Principles

Loose Coupling

Services should depend minimally on each other.

Bad:

Order Service directly accesses Payment DB

Good:

Order Service calls Payment API

High Cohesion

Everything related to payments stays in:

Payment Service

Database Per Service

Each service owns its data.

Good:

Order DB
Payment DB
User DB

Bad:

Shared Database

Enterprise Architecture Example

E-Commerce System

API Gateway

|
+--- User Service

|
+--- Product Service

|
+--- Cart Service

|
+--- Order Service

|
+--- Payment Service

|
+--- Inventory Service

|
+--- Shipping Service

|
+--- Notification Service

Each service has:

Own Database
Own Deployment
Own Monitoring
Own Logs

⚖️ Comparisons

🏗️ Real-World Scenarios

Scenario 1: Flash Sale

Problem:

Traffic suddenly increases 20x.

Monolith:

Scale entire application

Microservices:

Scale only Product Service
Scale only Inventory Service

Outcome:

Reduced infrastructure cost.

Scenario 2: Payment Failure

Problem:

Payment provider unavailable.

Solution:

Circuit Breaker
Fallback
Retry Mechanism

Outcome:

Application remains available.

Scenario 3: Independent Team Deployment

Problem:

Payment team releases daily.

Inventory team releases monthly.

Solution:

Independent deployment pipelines.

Outcome:

Faster feature delivery.

🚀 Performance Considerations

Network Latency

Microservices communicate through networks.

Avoid excessive service-to-service calls.

Database Calls

Minimize cross-service database access.

Serialization Cost

JSON conversion adds CPU overhead.

Use:

gRPC
Protocol Buffers

for high-performance communication.

Caching

Use:

Redis

to reduce API calls.

Connection Pooling

Use:

HikariCP

for database connections.

🏢 Enterprise Usage

Large organizations typically use:

Spring Boot
Spring Cloud
Kafka
Docker
Kubernetes
Redis
Prometheus
Grafana
ELK Stack

A typical production flow:

Client
|
API Gateway
|
Microservices
|
Kafka
|
Databases
|
Monitoring Stack

❌ Common Mistakes

Creating Too Many Services

100 services for a small application.

Shared Database

Breaks service independence.

Ignoring Monitoring

Leads to production troubleshooting nightmares.

Distributed Transactions Everywhere

Creates complexity.

Prefer Saga Pattern.

Synchronous Communication Only

Can cause cascading failures.

Use Kafka where appropriate.

✅ Best Practices

• Design around business domains.
• One database per service.
• Use API Gateway.
• Implement Circuit Breakers.
• Centralize logs.
• Use Distributed Tracing.
• Automate deployments.
• Secure all APIs.
• Implement health checks.
• Monitor everything.

🎯 Interview Q&A

Q1: What is Microservices Architecture?

Answer: Architectural style where applications are divided into independently deployable services.

Q2: Why Microservices over Monolith?

Answer: Better scalability, deployment flexibility, fault isolation, and team autonomy.

Q3: What is Database Per Service?

Answer: Each microservice owns its database and data model.

Q4: What is Service Discovery?

Answer: Mechanism to locate service instances dynamically.

Q5: What is API Gateway?

Answer: Single entry point for all client requests.

Q6: What is Circuit Breaker?

Answer: Prevents repeated calls to failing services.

Q7: What is Saga Pattern?

Answer: Distributed transaction management using compensating actions.

Q8: Why is Kafka used in Microservices?

Answer: Enables asynchronous communication and event-driven architecture.

Q9: What is Eventual Consistency?

Answer: Data becomes consistent over time rather than immediately.

Q10: What are challenges of Microservices?

Answer:

• Monitoring
• Distributed transactions
• Network latency
• Data consistency
• Security

Q11: When should you NOT use Microservices?

Answer: Small applications with small teams and simple requirements.

Q12: What is the biggest production challenge?

Answer: Observability and troubleshooting across distributed services.

📋 Revision Cheat Sheet

• One service = One business capability.
• Independent deployment.
• Independent scaling.
• Database per service.
• Loose coupling.
• High cohesion.
• API Gateway recommended.
• Service Registry required.
• Circuit Breaker improves resilience.
• Kafka enables asynchronous communication.
• Avoid shared databases.
• Avoid distributed transactions when possible.
• Use Saga Pattern.
• Monitor every service.
• Centralize logs.
• Implement tracing.
• Secure APIs using JWT/OAuth2.
• Containerize using Docker.
• Orchestrate using Kubernetes.
• Design around business domains.