Micro Services

1. Basics (Detailed Answers)

❓ What are Micro-services?

Answer:

Micro-services is an architectural style where an application is divided into small, independent services, and each service is responsible for a specific business capability.

Each micro-service:

· Runs independently

· Has its own database (ideally)

· Communicates via APIs (REST) or messaging (events/queues)

· Can be developed, deployed, and scaled independently

�� Example:
In an e-commerce app:

· User Service

· Order Service

· Payment Service

· Inventory Service

Each works independently but together forms the system.

❓ Difference: Monolith vs Micro services

Feature	Monolith	Microservices
Architecture	Single codebase	Multiple small services
Deployment	One unit	Independent deployments
Scalability	Entire app scales	Individual services scale
Failure Impact	One bug → whole app down	Failure isolated
Development	Simple initially	Complex
Technology	Same stack	Can use different stacks

�� Simple line:

· Monolith = “All in one”

· Microservices = “Divide and manage independently”

❓ Advantages of Micro services

✅ 1. Independent Deployment

You can deploy one service without affecting others.

✅ 2. Scalability

Only scale what’s needed (e.g., scale Payment service during sales).

✅ 3. Fault Isolation

If one service fails, others can still work.

✅ 4. Technology Flexibility

Different services can use different technologies.

✅ 5. Faster Development (for large teams)

Teams can work independently on services.

❌ Disadvantages of Micro services

❌ 1. Complexity

Managing multiple services is hard.

❌ 2. Network Overhead

Services communicate over network → latency.

❌ 3. Data Consistency Issues

No single database → need eventual consistency.

❌ 4. Debugging Difficulty

Tracing issues across services is complex.

❌ 5. DevOps Requirement

Needs CI/CD, containerization (like Docker), orchestration (like Kubernetes)

❓ When should you NOT use Microservices?

�� This is a very important interview question

❌ Avoid Microservices when:

1. Small application

o Simple CRUD app → Monolith is better

2. Small team

o Micro-services need coordination, DevOps, monitoring

3. No DevOps maturity

o Without CI/CD, it becomes messy

4. Tight coupling in business logic

o If everything depends on everything

5. Early stage startup (MVP)

o Start simple → scale later

�� Best practice:
“Start with monolith, move to micro services when needed”

❓ SOA vs Microservices

Feature	SOA (Service-Oriented Architecture)	Microservices
Size	Large services	Small services
Communication	Often via ESB (Enterprise Service Bus)	Lightweight APIs (REST/events)
Coupling	More coupled	Loosely coupled
Deployment	Less independent	Fully independent
Focus	Enterprise-level reuse	Business capability focus

�� Key Difference:

· SOA uses centralized ESB

· Microservices use decentralized communication

❓ What is a Bounded Context?

Answer:

Bounded Context is a concept from Domain-Driven Design (DDD), which defines a clear boundary where a specific business logic applies.

Each micro service should represent one bounded context.

�� Example (E-commerce):

· User Context → handles users

· Order Context → handles orders

· Payment Context → handles payments

Each context:

· Has its own data

· Has its own logic

· Does NOT interfere with others

�� Simple line:
“Bounded Context defines the boundary of a micro-service.”

⚙️

2. Core Concepts (Detailed Answers)

❓ What is API Gateway? Why is it used?

Answer:

API Gateway is a single entry point for all client requests in a micro services architecture.

Instead of clients calling multiple services directly, they call the API Gateway, which routes requests to the appropriate micro service.

✅ Why use API Gateway?

1. Single Entry Point

1. Client doesn’t need to know all services

2. Routing

1. Routes request to correct microservice

3. Authentication & Authorization

1. Central place to validate JWT tokens

4. Rate Limiting & Security

1. Prevent abuse

5. Aggregation

1. Combine responses from multiple services into one

�� Example:

Client → API Gateway → Order Service + User Service → Combined Response

�� One-liner:

�� “API Gateway acts as a reverse proxy that handles routing, security, and aggregation.”

❓ What is Service Discovery?

Answer:

In micro-services, services are dynamic (they scale up/down, change IPs).
Service Discovery helps services find each other dynamically.

�� Types:

1. Client-side discovery

1. Client finds service via registry

2. Server-side discovery

1. Load balancer/API Gateway finds service

�� Example tools:

· Eureka

· Consul

�� One-liner:

�� “Service Discovery helps services locate each other without hard-coding URLs.”

❓ What is Load Balancing?

Answer:

Load Balancing distributes incoming requests across multiple instances of a service to ensure high availability and performance.

�� Types:

1. Client-side load balancing

2. Server-side load balancing

�� Example:

If you have 3 instances of Order Service → requests are distributed evenly.

�� Benefits:

· Avoid overload

· Improve performance

· Increase reliability

�� One-liner:

�� “Load balancing ensures traffic is evenly distributed across service instances.”

❓ What is Circuit Breaker Pattern?

Answer:

Circuit Breaker is a design pattern used to prevent cascading failures in microservices.

�� Problem:

If Service A calls Service B and B is down → A keeps retrying → system crashes

�� Solution:

Circuit Breaker stops calls temporarily when failures exceed a threshold.

�� States:

1. Closed → Normal operation

2. Open → Calls blocked

3. Half-Open → Test if service recovered

�� Example:

If Payment Service is down → Order Service stops calling it temporarily

�� One-liner:

�� “Circuit Breaker prevents system failure by stopping calls to failing services.”

❓ What is Configuration Management?

Answer:

Configuration Management is used to manage application settings externally, instead of hardcoding them.

�� Examples:

· Database connection strings

· API URLs

· Feature flags

�� Tools:

· Azure App Configuration

· Spring Cloud Config

�� Benefits:

· Change config without redeploying

· Environment-based configs (Dev, QA, Prod)

�� One-liner:

�� “Configuration management externalizes settings for flexibility and maintainability.”

❓ What is Distributed Logging?

Answer:

Distributed Logging is the practice of collecting and analyzing logs from multiple microservices in a centralized system.

�� Problem:

Each service has its own logs → hard to debug

�� Solution:

Centralized logging system collects all logs in one place

�� Tools:

· ELK Stack

· Splunk

�� Benefits:

· Easy debugging

· Track request flow

· Identify failures quickly

�� One-liner:

�� “Distributed logging centralizes logs from all services for easier debugging and monitoring.”

�� 3. Communication Between Services

❓ Synchronous vs Asynchronous Communication

�� Synchronous Communication

Answer:
In synchronous communication, one service calls another service and waits for the response.

�� Example:
Service A → calls Service B → waits → gets response

✅ Pros:

· Simple to implement

· Immediate response

❌ Cons:

· Tight coupling

· If one service is slow/down → entire flow affected

· Not scalable under heavy load

�� Asynchronous Communication

Answer:
In asynchronous communication, services communicate via messages/events, and the sender does not wait for a response.

�� Example:
Service A → sends message → continues work → Service B processes later

✅ Pros:

· Loose coupling

· Better scalability

· High resilience

❌ Cons:

· Complex

· Eventual consistency (not immediate)

�� One-liner:

�� “Synchronous is request-response, asynchronous is event/message-based without waiting.”

❓ REST vs Messaging (Queue-based systems)

�� REST (HTTP-based)

Answer:
REST uses HTTP APIs for communication between services.

�� Example:
Order Service → calls Payment API via HTTP

✅ Pros:

· Simple

· Easy debugging

· Widely used

❌ Cons:

· Tight coupling

· Dependent on availability

· Not ideal for high-scale systems

�� Messaging (Queue-based)

Answer:
Services communicate using a message broker and queues instead of direct calls.

�� Example:
Order Service → sends message to queue → Payment Service consumes it

✅ Pros:

· Loose coupling

· Reliable (messages stored in queue)

· Scalable

❌ Cons:

· Complex setup

· Debugging is harder

�� One-liner:

�� “REST is direct communication, messaging is indirect via queues.”

❓ What is Event-Driven Architecture?

Answer:

Event-driven architecture is a design where services communicate by producing and consuming events.

�� Flow:

· One service generates an event

· Other services listen and react

�� Example:
Order Placed → triggers:

· Payment Service

· Inventory Service

· Notification Service

�� Benefits:

· Loose coupling

· Highly scalable

· Real-time processing

�� One-liner:

�� “Services react to events instead of directly calling each other.”

❓ What is a Message Broker?

Answer:

A message broker is a system that handles communication between services by storing and delivering messages.

�� Responsibilities:

· Queue messages

· Deliver messages

· Ensure reliability

�� Examples:

· Apache Kafka

· RabbitMQ

�� Example:

Order Service → sends message → Broker → Payment Service consumes it

�� One-liner:

�� “Message broker acts as a middle layer to exchange messages between services.”

❓ How do microservices communicate securely?

Answer:

Security in microservices communication is handled at multiple levels:

�� 1. HTTPS / TLS

· Encrypts data in transit

�� 2. Authentication (JWT Tokens)

· Services validate identity using tokens

�� 3. API Gateway Security

· Central point for:

o Authentication

o Rate limiting

o Request validation

�� 4. Service-to-Service Security

· Mutual TLS (mTLS)

· Internal tokens

�� 5. Network Security

· Private networks / VPC

· Firewall rules

�� 6. Secrets Management

· Store credentials securely (not in code)

�� One-liner:

�� “Microservices communication is secured using HTTPS, JWT, API Gateway, and service-to-service authentication.”

��️ 4. Database & Data Management

❓ Database per Service Pattern

Answer:

In microservices, each service should have its own separate database, instead of sharing one.

�� Why?

· Loose coupling

· Independent deployment

· Better scalability

· Data ownership clarity

�� Example:

· User Service → User DB

· Order Service → Order DB

· Payment Service → Payment DB

⚠️ Important Rule:

�� “No other service should directly access another service’s database.”

�� One-liner:

�� “Each microservice owns its data.”

❓ Shared Database vs Separate Database

�� Shared Database ❌

· All services use one DB

· Easy initially

· But leads to:

o Tight coupling

o Schema conflicts

o Deployment issues

�� Separate Database ✅

· Each service has its own DB

· Better isolation

· Independent scaling

�� Interview Line:

�� “Shared database breaks microservices principles, so database per service is recommended.”

❓ How to manage transactions in Microservices?

Answer:

In microservices, we cannot use traditional ACID transactions across multiple services because each service has its own database.

�� Solution:

�� Use Distributed Transaction patterns, mainly:

· Saga Pattern (most common)

�� One-liner:

�� “We use eventual consistency and Saga pattern instead of traditional transactions.”

❓ What is Eventual Consistency?

Answer:

Eventual consistency means that data may not be consistent immediately, but it will become consistent after some time.

�� Example:

· Order created

· Payment processed after few seconds

· System becomes consistent eventually

�� Why needed?

Because services are independent and communicate asynchronously

�� One-liner:

�� “System becomes consistent over time instead of instantly.”

❓ What is Saga Pattern? ⭐ (VERY IMPORTANT)

Answer:

Saga pattern is used to manage distributed transactions across multiple microservices.

It breaks a large transaction into multiple smaller local transactions, and each service performs its part.

�� Two Types:

1. Choreography (Event-based)

· Services communicate via events

· No central controller

�� Example:
Order → Payment → Inventory → Notification

2. Orchestration (Central control)

· One central service controls flow

�� Example:
Order Service → calls Payment → calls Inventory

�� What if something fails?

�� Compensation Transactions

· Undo previous steps

�� Example:

1. Order Created

2. Payment Success

3. Inventory Failed ❌

�� Compensation:

· Cancel Payment

· Cancel Order

�� One-liner:

�� “Saga manages distributed transactions using a sequence of local transactions with rollback support.”

❓ CQRS Pattern (Command Query Responsibility Segregation)

Answer:

CQRS is a pattern where read and write operations are separated into different models.

�� Command = Write

· Create / Update / Delete

�� Query = Read

· Fetch data

�� Example:

· Write DB → optimized for transactions

· Read DB → optimized for fast queries

�� Why use CQRS?

· Improves performance

· Scales read/write independently

· Better flexibility

⚠️ Trade-off:

· More complexity

· Data synchronization needed

�� One-liner:

�� “CQRS separates read and write operations for better scalability and performance.”

�� 5. Security (Detailed, Interview-Ready)

❓ How do you secure microservices?

Answer:

I secure microservices using a multi-layered approach:

�� 1. Transport Security

· Use HTTPS/TLS for all external and internal communication

�� 2. Authentication

· Use token-based auth (mostly JWT)

�� 3. Authorization

· Role-based (RBAC) or policy-based access

�� 4. API Gateway

· Central entry point for validation, rate limiting, security

�� 5. Service-to-Service Security

· Use mTLS or internal tokens

�� 6. Secrets Management

· Store credentials securely (not in code)

�� 7. Network Security

· Private networks (VPC), firewalls

�� 8. Monitoring & Logging

· Detect suspicious activity

�� One-liner:

�� “I use layered security—HTTPS, JWT, API Gateway, and service-to-service authentication—to protect microservices.”

❓ Authentication vs Authorization

�� Authentication (Who are you?)

· Verifies identity

· Example: Login with username/password → get token

�� Authorization (What can you access?)

· Defines permissions

· Example: Admin can delete user, normal user cannot

�� Example:

· Login → Authentication

· Access admin API → Authorization

�� One-liner:

�� “Authentication verifies identity, authorization controls access.”

❓ JWT in Microservices

Answer:

JWT (JSON Web Token) is used for stateless authentication.

�� Flow:

1. User logs in

2. Server generates JWT

3. Client sends JWT with every request

4. Services validate token

�� Structure:

· Header

· Payload (user info, roles)

· Signature

�� Benefits:

· Stateless (no session storage)

· Scalable

· Fast validation

⚠️ Best Practices:

· Short expiry

· Use HTTPS

· Don’t store sensitive data in payload

�� One-liner:

�� “JWT enables stateless and scalable authentication across microservices.”

❓ API Gateway Security Role

Answer:

API Gateway acts as a security layer between clients and microservices.

�� Responsibilities:

1. Authentication

o Validate JWT tokens

2. Authorization

o Check roles/permissions

3. Rate Limiting

o Prevent abuse

4. Request Validation

o Validate input

5. SSL Termination

o Handle HTTPS

�� Example:

Client → API Gateway → validates token → forwards request

�� One-liner:

�� “API Gateway centralizes security and protects backend services.”

❓ How to handle secure communication between services?

Answer:

Service-to-service communication is secured using:

�� 1. HTTPS / TLS

· Encrypt internal traffic

�� 2. Mutual TLS (mTLS)

· Both services authenticate each other

�� 3. Internal Tokens

· Services validate requests using tokens

�� 4. Network Isolation

· Private network (no public exposure)

�� 5. Service Identity

· Each service has its own identity

�� 6. API Gateway / Service Mesh (optional)

· Centralized control

�� Example:

Order Service → calls Payment Service using mTLS + token

�� One-liner:

�� “Secure service communication using HTTPS, mTLS, and internal authentication.”

�� 6. Deployment & DevOps (Detailed Answers)

❓ What is Containerization?

Answer:

Containerization is a technique where an application and its dependencies are packaged together into a lightweight, portable unit called a container.

�� Why use it?

· Runs consistently across environments (dev, QA, prod)

· Eliminates “it works on my machine” problem

· Fast startup and lightweight compared to VMs

�� Example:

Your .NET API + runtime + libraries → packaged into a container → runs anywhere

�� One-liner:

�� “Containerization packages app + dependencies into a portable unit.”

❓ What is Docker?

Answer:

Docker is a platform used to build, run, and manage containers.

�� Key components:

· Dockerfile → defines how to build image

· Image → blueprint of application

· Container → running instance of image

�� Example flow:

Code → Dockerfile → Docker Image → Run as Container

�� Benefits:

· Easy deployment

· Consistency

· Isolation

�� One-liner:

�� “Docker is a tool to create and run containers.”

❓ What is Kubernetes?

Answer:

Kubernetes is a system used to manage, scale, and orchestrate containers in production.

�� Responsibilities:

· Auto-scaling

· Load balancing

· Self-healing (restart failed containers)

· Deployment management

�� Example:

If one container crashes → Kubernetes automatically restarts it

�� One-liner:

�� “Kubernetes manages and scales containers automatically.”

❓ What is CI/CD Pipeline?

Answer:

CI/CD is a process that automates building, testing, and deploying applications.

�� CI (Continuous Integration)

· Code is automatically built and tested after every change

�� CD (Continuous Delivery/Deployment)

· Code is automatically deployed to environments

�� Flow:

Code commit → Build → Test → Deploy

�� Tools:

· Jenkins

· Azure DevOps

· GitHub Actions

�� One-liner:

�� “CI/CD automates build, test, and deployment process.”

❓ Blue-Green Deployment vs Canary Deployment

�� Blue-Green Deployment

Answer:

· Two environments: Blue (old) & Green (new)

· Switch traffic instantly to new version

✅ Pros:

· Zero downtime

· Easy rollback

❌ Cons:

· Needs double infrastructure

�� Canary Deployment

Answer:

· Release new version to small % of users first

· Gradually increase traffic

✅ Pros:

· Low risk

· Real-world testing

❌ Cons:

· More complex monitoring

�� Difference (one line):

�� “Blue-Green switches all traffic at once, Canary releases gradually.”

❓ What is Rolling Deployment?

Answer:

Rolling deployment updates application gradually by replacing old instances with new ones one by one.

�� Example:

· 10 instances running

· Replace 2 at a time → until all updated

✅ Benefits:

· No downtime

· Controlled update

❌ Risk:

· Mixed versions during deployment

�� One-liner:

�� “Rolling deployment updates services gradually without downtime.”

�� 7. Observability & Monitoring (Detailed Answers)

❓ What is Centralized Logging?

Answer:

Centralized logging means collecting logs from all microservices into a single system so they can be searched and analyzed together.

�� Problem it solves:

· Each service has its own logs

· Hard to debug across services

�� Solution:

· Send all logs to one place (log server)

�� Example:

User request fails → check logs from:

· API Gateway

· Order Service

· Payment Service
�� all in one dashboard

�� Benefits:

· Easy debugging

· Faster issue resolution

· Better visibility

�� One-liner:

�� “Centralized logging collects logs from all services into one place for easier debugging.”

❓ What is Distributed Tracing?

Answer:

Distributed tracing tracks a single request across multiple microservices.

�� Why needed?

In microservices:

· One request → goes through multiple services

· Hard to track flow

�� How it works:

· Each request gets a Trace ID

· Passed across services

· Helps track entire journey

�� Example:

Client → API Gateway → Order → Payment → Inventory
�� All linked with same Trace ID

�� Benefits:

· Identify bottlenecks

· Debug performance issues

· Understand request flow

�� One-liner:

�� “Distributed tracing tracks a request across multiple services using a trace ID.”

❓ Tools (Monitoring & Observability)

�� ELK Stack

Full form:

· Elasticsearch → storage & search

· Logstash → collect logs

· Kibana → visualize logs

�� Used for centralized logging

�� Prometheus

· Collects metrics (CPU, memory, requests)

· Time-series database

�� Used for monitoring system health

�� Grafana

· Dashboard tool

· Visualizes data from Prometheus

�� Used for graphs, alerts, dashboards

�� One-liner:

�� “ELK for logs, Prometheus for metrics, Grafana for visualization.”

❓ What is Health Check in Microservices?

Answer:

Health check is a mechanism to verify whether a service is running and functioning correctly.

�� Types:

1. Liveness Check

o Is service alive?

o If not → restart

2. Readiness Check

o Is service ready to handle traffic?

�� Example:

· DB down → service not ready

· Kubernetes stops sending traffic

�� Benefits:

· Automatic recovery

· Better reliability

�� One-liner:

�� “Health checks ensure service is alive and ready to handle requests.”

⚡ 8. Resilience & Fault Tolerance (Detailed Answers)

❓ What happens if one service fails?

Answer:

In microservices, failure is inevitable, so systems are designed to handle failure gracefully, not avoid it completely.

�� Without proper handling:

· One service fails

· Other services keep calling it

· Leads to cascading failure → entire system down

�� With resilience patterns:

· Failure is isolated

· System continues partially

· Graceful degradation (limited functionality)

�� Example:

Payment service down →

· Order service still works

· Payment marked as “Pending” instead of failing system

�� One-liner:

�� “Failure should be isolated so the system continues to work partially.”

❓ Retry Pattern

Answer:

Retry pattern means retrying a failed request automatically after a short delay.

�� Why?

Some failures are temporary (network issue, service busy)

�� Types:

· Immediate retry

· Delayed retry

· Exponential back-off (recommended)

�� Example:

Order → Payment fails → retry after 2s → success

⚠️ Risk:

Too many retries → overload system

�� One-liner:

�� “Retry pattern handles temporary failures by retrying requests with delay.”

❓ Circuit Breaker Pattern ⭐

Answer:

Circuit Breaker prevents continuous calls to a failing service, avoiding system overload.

�� States:

1. Closed

o Normal calls

2. Open

o Stop calls when failure threshold reached

3. Half-Open

o Test if service is back

�� Example:

Payment service failing →
Circuit opens →
Order service stops calling → returns fallback response

�� Benefits:

· Prevent cascading failures

· Improve system stability

�� One-liner:

�� “Circuit breaker stops calls to failing services to protect the system.”

❓ Bulkhead Pattern

Answer:

Bulkhead pattern isolates resources so that failure in one part doesn’t affect others.

�� Real-life analogy:

Like compartments in a ship—if one compartment floods, others stay safe

�� In microservices:

· Separate thread pools

· Separate resources per service

�� Example:

Payment service overloaded →
Order service still works independently

�� Benefits:

· Fault isolation

· Improved stability

�� One-liner:

�� “Bulkhead isolates failures so one service doesn’t impact others.”

❓ Timeout Handling

Answer:

Timeout defines how long a service should wait for a response before failing.

�� Why important?

· Prevents long waiting

· Frees resources

�� Example:

Order service waits 2 seconds for Payment →
If no response → timeout → fallback

�� Best practice:

· Always set timeout

· Combine with retry + circuit breaker

�� One-liner:

�� “Timeout ensures system doesn’t wait indefinitely for a response.”

�� 9. Design Patterns (Deep + Interview-Ready)

❓ API Gateway Pattern

Answer:

API Gateway is a pattern where a single entry point sits in front of all microservices and handles client requests.

�� Responsibilities:

· Routing requests

· Authentication & Authorization

· Rate limiting

· Response aggregation

�� Example:

Mobile app → API Gateway → calls:

· User Service

· Order Service
�� returns combined response

�� When to use:

· Multiple microservices

· Need centralized security & routing

⚠️ Trade-off:

· Can become a bottleneck if not designed well

�� One-liner:

�� “API Gateway centralizes client communication and security.”

❓ Saga Pattern ⭐ (Most Important)

Answer:

Saga pattern is used to manage distributed transactions across microservices.

�� Idea:

Break one big transaction into multiple local transactions

�� Types:

1. Choreography

· Event-based

· No central controller

2. Orchestration

· Central service controls flow

�� Example:

Order → Payment → Inventory

If Inventory fails:
�� Compensation:

· Refund payment

· Cancel order

�� When to use:

· Multi-service transactions

· No shared DB

�� One-liner:

�� “Saga ensures data consistency using local transactions and compensation.”

❓ CQRS (Command Query Responsibility Segregation)

Answer:

CQRS separates read and write operations into different models.

�� Command (Write)

· Insert / Update

�� Query (Read)

· Fetch data

�� Example:

· Write DB → optimized for transactions

· Read DB → optimized for fast queries

�� When to use:

· High read/write load

· Complex queries

⚠️ Trade-off:

· More complexity

· Data sync required

�� One-liner:

�� “CQRS separates read and write for better performance and scalability.”

❓ Event Sourcing

Answer:

Event Sourcing stores state changes as a sequence of events, instead of storing only the current state.

�� Instead of:

Saving final state → balance = 500

�� Store events:

· +1000 deposited

· -500 withdrawn

�� Benefits:

· Full audit history

· Easy debugging

· Replay events

�� When to use:

· Audit-heavy systems (banking, finance)

· Event-driven systems

⚠️ Trade-off:

· Complex

· Storage overhead

�� One-liner:

�� “Event sourcing stores all changes as events instead of current state.”

❓ Strangler Pattern

Answer:

Strangler pattern is used to gradually migrate a monolith to microservices.

�� Approach:

· Replace parts of monolith step by step

· Route traffic to new services

�� Example:

· Old Order module in monolith

· Build new Order microservice

· Gradually shift traffic

�� Benefits:

· No big-bang migration

· Low risk

�� When to use:

· Legacy system migration

�� One-liner:

�� “Strangler pattern replaces monolith piece by piece with microservices.”

❓ Sidecar Pattern

Answer:

Sidecar pattern adds a helper container/service alongside the main service to handle cross-cutting concerns.

�� Responsibilities:

· Logging

· Monitoring

· Security

· Configuration

�� Example:

Main service + sidecar container for logging

�� Benefits:

· Separation of concerns

· Reusable components

�� Where used:

· Service mesh (like Istio)

�� One-liner:

�� “Sidecar handles supporting tasks without changing main service.”

�� 10. Testing in Microservices (Deep + Interview-Ready)

❓ Unit Testing in Micro-services

Answer:

Unit testing focuses on testing individual components or functions in isolation, without external dependencies.

�� What we test:

· Business logic

· Service methods

· Utility functions

�� How:

· Mock external dependencies (DB, APIs)

�� Example:

Testing Order Service logic without calling Payment Service

✅ Benefits:

· Fast

· Easy to automate

· Helps catch bugs early

⚠️ Limitation:

· Doesn’t test real service interaction

�� One-liner:

�� “Unit testing validates individual components in isolation using mocks.”

❓ Integration Testing

Answer:

Integration testing verifies how multiple components or services work together.

�� What we test:

· API calls

· Database interaction

· Service communication

�� Example:

Order Service → calls Payment Service → verify response

✅ Benefits:

· Tests real interactions

· Detects integration issues

❌ Challenges:

· Slower than unit tests

· Requires environment setup

�� One-liner:

�� “Integration testing ensures different components/services work together correctly.”

❓ Contract Testing ⭐ (Very Important)

Answer:

Contract testing ensures that two services agree on how they communicate—especially request and response formats.

�� Problem:

Service A expects response in one format
Service B changes response → breaks A

�� Solution:

Define a contract between services

�� Example:

Order Service expects:

{
"status": "success",
"amount": 100
}

If Payment Service changes it → test fails immediately

✅ Benefits:

· Prevents breaking changes

· Ensures compatibility

�� One-liner:

�� “Contract testing ensures services follow agreed API contracts.”

❓ What is Consumer-Driven Contract Testing?

Answer:

Consumer-driven contract testing is where the consumer service defines the contract, and the provider must satisfy it.

�� Flow:

1. Consumer (e.g., Order Service) defines expectations

2. Contract is created

3. Provider (e.g., Payment Service) validates against contract

�� Example:

Order Service says:
�� “I expect status + amount”

Payment Service must return that format

�� Popular Tool:

· Pact

✅ Benefits:

· Safer deployments

· Independent development

· Early detection of breaking changes

�� One-liner:

�� “Consumer defines expectations, provider validates against them.”

�� 11. Advanced Microservices (Deep + Interview-Ready)

❓ How do you handle distributed transactions?

Answer:

In microservices, we avoid traditional ACID transactions across services and use eventual consistency with patterns like Saga.

�� Approach:

· Break transaction into multiple local transactions

· Each service updates its own DB

· Use events to coordinate

�� If failure occurs:

�� Use compensation transactions (rollback steps)

�� Example:

Order → Payment → Inventory
If Inventory fails → Refund Payment + Cancel Order

�� One-liner:

�� “I use Saga pattern with compensation to handle distributed transactions.”

❓ How do you debug microservices in production?

Answer:

Debugging microservices requires observability tools + tracing + logs.

�� Approach:

1. Centralized Logging

o Use ELK Stack

2. Distributed Tracing

o Track request using Trace ID

3. Monitoring

o Metrics using Prometheus

o Dashboards via Grafana

4. Correlation IDs

o Track request across services

�� One-liner:

�� “I use logs, metrics, and distributed tracing to debug issues across services.”

❓ How do you ensure data consistency?

Answer:

Since each service has its own database, we ensure consistency using:

�� Techniques:

· Eventual consistency

· Saga pattern

· Idempotent operations (avoid duplicate processing)

· Message queues

�� Example:

Order created → event triggers Payment → eventually consistent

�� One-liner:

�� “I ensure data consistency using eventual consistency with Saga and idempotency.”

❓ How do you scale microservices?

Answer:

Microservices are scaled independently based on load.

�� Types of scaling:

1. Horizontal Scaling

o Add more instances

2. Auto-scaling

o Based on CPU/traffic

Tools:

· Kubernetes

�� Example:

High traffic on Payment → scale only Payment service

�� One-liner:

�� “I scale microservices independently using horizontal and auto-scaling.”

❓ How do you manage versioning of APIs?

Answer:

API versioning ensures backward compatibility when APIs change.

�� Methods:

1. URL versioning

o /api/v1/orders

2. Header versioning

o Version in request header

�� Best practices:

· Don’t break existing clients

· Deprecate old versions gradually

�� One-liner:

�� “I use versioning to maintain backward compatibility while evolving APIs.”

❓ How do you avoid tight coupling?

Answer:

Micro-services should be loosely coupled to remain independent.

�� Techniques:

· Use API contracts

· Prefer asynchronous communication (events)

· Avoid shared database

· Use DTOs instead of internal models

�� Example:

Order service doesn’t depend on Payment DB, only API/events

�� One-liner:

�� “I use APIs, events, and separate databases to keep services loosely coupled.”

❓ How do you handle schema changes?

Answer:

Schema changes must be handled carefully to avoid breaking services.

�� Strategies:

1. Backward-compatible changes

o Add new fields, don’t remove old ones

2. Versioning

o Maintain multiple versions

3. Database migration tools

o Controlled updates

4. Contract testing

o Ensure compatibility

�� Example:

Add new field → old services still work

�� One-liner:

�� “I handle schema changes using backward compatibility and versioning.”

12.Scenario-Based Questions (Deep + Interview-Ready)

❓ Design an E-commerce System using Microservices

Answer:

I would design the system by breaking it into independent business services:

�� Core Services:

· User Service

· Product Service

· Order Service

· Payment Service

· Inventory Service

· Notification Service

�� Architecture Flow:

Client → API Gateway → Microservices

· API Gateway handles routing, auth, rate limiting

· Services communicate via REST (sync) or events (async)

�� Database:

· Each service has its own DB (database per service)

�� Communication:

· Order → Payment → Inventory via events (async)

�� Deployment:

· Containerized using Docker

· Managed via Kubernetes

�� Observability:

· Logs: ELK Stack

· Metrics: Prometheus

�� One-liner:

�� “I design microservices based on business capabilities with independent deployment, async communication, and strong observability.”

❓ How would you handle payment failure in a distributed system?

Answer:

I handle this using Saga pattern with compensation logic.

�� Flow:

1. Order Created

2. Payment Initiated

3. Payment Failed ❌

�� Compensation:

· Cancel Order

· Notify user

�� Optional:

· Retry payment (with limits)

· Mark order as “Pending Payment”

�� One-liner:

�� “I use Saga with compensation to rollback failed transactions.”

❓ What happens if Order service succeeds but Payment fails?

Answer:

This is a classic distributed transaction problem.

�� Solution:

Use Saga pattern:

�� Flow:

1. Order created ✅

2. Payment failed ❌

�� Compensation:

· Cancel Order

· Release inventory (if reserved)

�� Alternative:

· Keep order in “Pending” state

· Allow retry

�� One-liner:

�� “I handle it using Saga with rollback or retry strategy.”

❓ How would you migrate Monolith to Micro-services?

Answer:

I use the Strangler Pattern for gradual migration.

�� Steps:

1. Identify modules (Order, User, etc.)

2. Extract one service at a time

3. Route traffic to new service

4. Gradually remove monolith parts

�� Example:

· Move Order module first

· Keep rest in monolith

�� Benefits:

· Low risk

· No downtime

�� One-liner:

�� “I migrate gradually using Strangler pattern instead of big-bang rewrite.”

❓ How do you handle high traffic (scaling)?

Answer:

I handle high traffic using scaling + caching + async processing.

�� Techniques:

1. Horizontal Scaling

· Add more service instances

2. Auto-scaling

· Use Kubernetes

3. Load Balancing

· Distribute traffic evenly

4. Caching

· Use Redis for frequently accessed data

5. Asynchronous Processing

· Use queues for heavy tasks

6. CDN (for static content)

�� Example:

During sale → scale Order & Payment services

�� One-liner:

�� “I scale using horizontal scaling, caching, and async processing.”

�� 13. Must-Prepare Practical Answers (Interview-Ready)

❓ Explain a microservices project you worked on

Answer:

“In my recent project, I worked on an e-commerce system where we implemented a micro-services architecture.

We had multiple services like User Service, Order Service, Payment Service, and Inventory Service. Each service had its own database following the database-per-service pattern.

We used an API Gateway for routing and security, and services communicated using a mix of REST APIs (for real-time calls) and asynchronous messaging for background processing.

For deployment, we containerized services using Docker and managed them with Kubernetes.

We also implemented centralized logging using ELK Stack and monitoring using Prometheus.

This architecture helped us scale services independently and improve system reliability.”

❓ What challenges did you face?

Answer:

“Some key challenges I faced were:

1. Service communication complexity

2. Handling distributed transactions

3. Debugging issues across multiple services

4. Managing data consistency

Initially, debugging and tracing requests across services was difficult, especially when failures occurred in between services.”

❓ How did you solve service communication issues?

Answer:

“To handle communication effectively, I used a hybrid approach:

· Used REST APIs for synchronous communication where immediate response was required

· Used asynchronous messaging for decoupled communication

This reduced dependency between services and improved scalability.

I also implemented retry and timeout mechanisms to handle temporary failures.”

❓ How did you handle failures?

Answer:

“I handled failures using resilience patterns:

· Retry pattern for temporary failures

· Circuit Breaker to prevent cascading failures

· Timeouts to avoid long waiting

For distributed transactions, I used the Saga pattern with compensation logic.

For example, if payment failed after order creation, I triggered a rollback to cancel the order.”

❓ How did you secure APIs?

Answer:

“I secured APIs using multiple layers:

· Used HTTPS for encrypted communication

· Implemented JWT-based authentication

· Used API Gateway for centralized security and rate limiting

· Applied role-based authorization

· Secured service-to-service communication using internal authentication

I also ensured sensitive data was not exposed in API responses.”

Microservices Interview Questions For Freshers

1) What are Microservices?

Microservices are an architectural style where an application is divided into small independent services.
Each service handles one business capability and can be developed, deployed, and scaled separately.

Example: In Amazon:

· User Service

· Product Service

· Order Service

· Payment Service

2) How do microservices differ from Monolithic architecture?

Monolithic	Microservices
Single codebase	Multiple small services
Single deployment	Independent deployment
Hard to scale specific parts	Scale only required service
One technology stack	Different tech stacks possible

3) What are the key features of Microservices?

· Independent deployment

· Loose coupling

· High scalability

· Fault isolation

· Technology diversity

· Decentralized data management

4) Name the main components of Microservices

· API Gateway

· Service Discovery

· Load Balancer

· Database

· Message Broker

· Monitoring/Logging

· Authentication Service

5) Explain the role of an API Gateway in Microservices

An API Gateway acts as a single entry point.

Responsibilities:

· Routing requests

· Authentication

· Rate limiting

· Load balancing

· Caching

Example: Client → API Gateway → Order Service / Payment Service

6) What is service discovery in Microservices

Service discovery helps services find each other dynamically.

Tools:

· Eureka

· Consul

· Kubernetes DNS

7) What is a container and why is it used in Microservices

A container packages app + dependencies.

Example:
Docker

Benefits:

· Same behavior everywhere

· Lightweight

· Easy deployment

8) How do Microservices communicate with each other

Synchronous

· HTTP/HTTPS REST

· gRPC

Asynchronous

· Message queues/events via RabbitMQ / Apache Kafka

9) How would you handle a Microservices failure

Use:

· Retry pattern

· Circuit breaker

· Fallback

· Timeout

· Monitoring alerts

Example tool:
Polly in .NET

10) How can you ensure backward compatibility in Microservices

· API versioning

· Add new fields instead of changing old ones

· Avoid breaking changes

Example:

/api/v1/orders
/api/v2/orders

Microservices Interview Questions for 1 Year Experienced

11) What is the meaning of OAuth and why is it used

OAuth 2.0 is an authorization protocol.

Used to allow secure access without sharing passwords.

Example:
Login with Google

12) What is CQRS pattern in microservices? What problem does it solve

CQRS separates:

· Command → Write

· Query → Read

Solves:

· Performance issues

· Complex read/write logic

13) Compare API gateway and load balancer

API Gateway	Load Balancer
Routes requests	Distributes traffic
Auth, caching	Traffic balancing only
Works at app layer	Works at network/app layer

14) What are some common microservices design principles

· Single Responsibility

· Loose Coupling

· High Cohesion

· Statelessness

· Fail Fast

15) How do you ensure security

· HTTPS

· JWT Tokens

· OAuth2

· API Gateway auth

· Encrypt sensitive data

16) Ways to achieve synchronous and asynchronous communication

Synchronous:

· REST

· gRPC

Asynchronous:

· Kafka

· RabbitMQ

· Azure Service Bus

17) How do you implement rate limiting

Limit requests per user/IP.

Example:
100 requests/minute.

Types:

· Fixed window

· Sliding window

· Token bucket

18) What is event driven architecture in microservices

Services communicate using events.

Example:
Order Created → Payment Service listens → Inventory Service listens

19) What is idempotency and why is it important

Same request multiple times = same result.

Example:
Payment API should not charge twice.

20) What is database sharding and why is it used

Splitting database into smaller parts.

Example:
Users A–M in DB1
N–Z in DB2

Improves scalability.

Advanced Microservices Interview Questions

21) How do you handle data consistency

Use:

· Saga pattern

· Eventual consistency

· Distributed transactions (rare)

22) What is canary deployment

Release new version to small users first.

Example:
5% users → monitor → 100%

23) How would you monitor microservices

Use:

· Logs

· Metrics

· Tracing

Tools:
Prometheus
Grafana
Jaeger

24) What are the DDD principles

Domain-Driven Design:

· Entities

· Value Objects

· Aggregates

· Repositories

· Bounded Context

25) How do you design for scalability

· Stateless services

· Caching

· Load balancing

· Horizontal scaling

26) What is chaos engineering and how is it applied

Testing system by intentionally causing failures.

Example:
Stop one service and observe behavior.

Tool:
Chaos Monkey

27) How do you perform logging in distributed systems

Use centralized logging.

Tools:
Elasticsearch + Logstash + Kibana

(ELK Stack)

28) What is the purpose of a retry pattern

Automatically retries failed requests.

Useful for temporary failures.

29) What are sidecars in microservices

A sidecar is a helper container attached to a service.

Example:
Logging, monitoring, proxy.

In Istio Envoy sidecar.

30) Best practices for deploying microservices in production

· CI/CD

· Monitoring

· Logging

· Auto-scaling

· Security

· Health checks

· Backup strategy

-----------------------------------------------------------------------------------------------------------------------------------------------------------

1) DDD / Define Microservices Boundaries

Domain-Driven Design helps split services based on business domains.

Example in an e-commerce app:

· User Service → user management

· Product Service → products

· Order Service → orders

· Payment Service → payments

Each service should have:

· its own business logic

· its own database

· independent deployment

This is called Bounded Context.

2) Microservices Communication - REST API

REST is synchronous communication over HTTP.

Example:

GET /api/products/1
POST /api/orders

Pros:

· simple

· easy to understand

Cons:

· service dependency

· slow if downstream service is down

3) Service Discovery & Registration Pattern

Services register themselves in a registry.

Example tools:

· Eureka

· Consul

· Kubernetes

Flow:

Order Service → register in Eureka
Payment Service → ask Eureka for Order Service location

4) Message Brokers

A message broker transfers messages between services.

Examples:

· RabbitMQ

· ActiveMQ

· Azure Service Bus

Used for async communication.

5) Event Streaming with Kafka

Apache Kafka stores streams of events.

Example:

Order Created event → Kafka → Payment & Inventory consume it.

Benefits:

· high throughput

· event replay

· decoupled services

6) Single Database per Microservice

Each service owns its own DB.

Example:

· User Service → UserDB

· Product Service → ProductDB

· Order Service → OrderDB

Benefits:

· loose coupling

· independent scaling

7) Microservices Deployment (Docker & Kubernetes)

Docker packages app into containers.
Kubernetes manages containers.

Kubernetes features:

· auto scaling

· self healing

· rolling updates

8) What are Virtual Machines (VM)

A VM is a virtual computer with its own OS.

Example:

Hardware → Hypervisor → VM → Guest OS → App

9) Load Balancer

A load balancer distributes traffic among instances.

Example:

User Requests → Load Balancer → Service1 / Service2 / Service3

Types:

· Round Robin

· Least Connections

10) What are Containers

Containers package:

· code

· runtime

· libraries

They share host OS.

Example:
Docker container.

11) Virtual Machine vs Container

VM	Container
Full OS	Shared OS
Heavy	Lightweight
Slow startup	Fast startup
More resources	Less resources

12) Distributed Transaction in Microservices

A transaction involving multiple services/databases.

Example:

Order Service + Payment Service + Inventory Service.

Hard because no single DB transaction.

13) Learn Saga Pattern

Saga Pattern manages distributed transactions using local transactions.

Example:

1. Create Order

2. Process Payment

3. Reduce Inventory

If payment fails → cancel order.

Types:

· Choreography

· Orchestration

14) The Gateway Pattern

An API Gateway is a single entry point.

Responsibilities:

· auth

· routing

· caching

· rate limiting

Example:
Ocelot / Kong

15) Handling Microservices Failure

Use:

· Retry

· Timeout

· Circuit Breaker

· Fallback

16) Microservice Resilience Patterns

Common patterns:

· Retry

· Circuit Breaker

· Bulkhead

· Timeout

· Fallback

These improve reliability.

17) The Circuit Breaker Pattern

Stops repeated calls to a failed service.

States:

1. Closed → normal

2. Open → block requests

3. Half-open → test request

Example in .NET:
Polly

Flow:

Request → Service Down → Circuit Open → Fail Fast

*************************************************************************************************************************************Service Bus is like a middleman between services.

In microservices, one service often needs to send data to another.

Example:

· Order Service

· Payment Service

· Email Service

Without Service Bus:

Order Service ---> Payment Service
Order Service ---> Email Service

Order Service must know all services directly.

This creates tight coupling.

With Service Bus:

Order Service ---> Service Bus ---> Payment Service
---> Email Service

Now Order Service sends one message to bus.

Bus delivers it.

So services are loosely coupled.

Real-time example

You order from Amazon.

When order placed:

1. Order Service creates order

2. Sends message: "OrderPlaced"

Service Bus receives it and forwards to:

· Payment Service → deduct money

· Inventory Service → reduce stock

· Notification Service → send email/SMS

OrderPlaced Event
        |
   Service Bus
   /    |    \
Payment Inventory Notification

Why use Service Bus?

✅ Decoupling
Services don’t know each other.

✅ Reliability
If one service is down, message waits.

✅ Scalability
Multiple consumers can process messages.

✅ Retry mechanism
Failed messages can retry.

Example in .NET / Azure

Microsoft has Azure Service Bus.

Example:

var client = new ServiceBusClient(connectionString);
var sender = client.CreateSender("orders");

await sender.SendMessageAsync(new ServiceBusMessage("OrderPlaced"));

Difference between Queue and Topic

Queue → one-to-one

Producer ---> Queue ---> One Consumer

Example:
One order processed by one worker.

Topic → one-to-many

Producer ---> Topic ---> many subscribers

Example:
OrderPlaced event goes to many services.

Interview line:

Service Bus is a messaging system used in microservices to enable asynchronous communication and loose coupling between services.

1) Queue → One-to-One communication

A message is consumed by only one receiver.

Example:

Order Service → Queue → Payment Service

If 5 messages come:

Msg1
Msg2
Msg3
Msg4
Msg5

and 2 workers are listening:

Worker1 gets Msg1, Msg3, Msg5
Worker2 gets Msg2, Msg4

Each message is processed once only.

Real-world example:

Food delivery app:

When customer places order:

OrderPlaced → Queue → Kitchen Service

Only one kitchen should prepare one order.

So Queue is used.

�� Use Queue when:

· One sender

· One receiver (or many competing workers)

· Process once

2) Topic → One-to-Many communication

A message is sent to multiple subscribers.

Example:

Order Service → Topic
↙ ↓ ↘
Payment Email Inventory

One message copies to all subscribers.

Example message:

OrderPlaced

Then:

· Payment Service gets it

· Email Service gets it

· Inventory Service gets it

All process same message.

Real-world example:

Amazon order placed.

Need to:

· deduct stock

· send email

· create invoice

One event can trigger all.

�� Use Topic when:

· One sender

· Multiple receivers

· Broadcast event

Simple trick to remember:

Queue = single line in bank
One customer → one counter

Topic = YouTube notification
One upload → all subscribers notified

Interview answer:

Queue is used for point-to-point communication where one message is processed by one consumer, while Topic is used for publish-subscribe communication where one message is delivered to multiple subscribers.

ServiceBusClient is a class used to connect your .NET application to Azure Service Bus.

Think of it as a main door.

Through this door you can create:

· Sender → send messages

· Receiver → receive messages

· Processor → automatically process messages

Example

Install package first:

dotnet add package Azure.Messaging.ServiceBus

Then:

using Azure.Messaging.ServiceBus;

string connectionString = "your_connection_string";

ServiceBusClient client = new ServiceBusClient(connectionString);

Now your app is connected.

1) Sender

Used to send messages to Queue or Topic.

ServiceBusSender sender = client.CreateSender("orders");

await sender.SendMessageAsync(
new ServiceBusMessage("OrderPlaced")
);

Example:

Order Service → Queue/Topic

2) Receiver

Used to receive messages manually.

ServiceBusReceiver receiver = client.CreateReceiver("orders");

ServiceBusReceivedMessage message = await receiver.ReceiveMessageAsync();

Console.WriteLine(message.Body.ToString());

3) Processor

Automatically listens for messages.

ServiceBusProcessor processor = client.CreateProcessor("orders");

processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

await processor.StartProcessingAsync();

This is like background listener.

Real-time Example

Amazon order system:

Order Service → Service Bus Queue → Payment Service

Order Service:

var sender = client.CreateSender("orders");
await sender.SendMessageAsync(new ServiceBusMessage("OrderPlaced"));

Payment Service:

var receiver = client.CreateReceiver("orders");

Simple meaning:

ServiceBusClient = connection object

Like:

SqlConnection

for SQL Server.

and

HttpClient

for API calls.

Similarly:

ServiceBusClient

for Azure Service Bus.

ServiceBusMessage is the actual message/data you send through Azure Service Bus.

Think:

· ServiceBusClient → connect to bus

· ServiceBusSender → sends

· ServiceBusMessage → what you send

Example:

var message = new ServiceBusMessage("OrderPlaced");

Here:

"OrderPlaced"

is the message body.

Then send:

await sender.SendMessageAsync(message);

Real-time Example

Amazon order:

OrderId: 101
UserId: 50
Amount: 500

Send as JSON:

var json = JsonSerializer.Serialize(new
{
    OrderId = 101,
    UserId = 50,
    Amount = 500
});

var message = new ServiceBusMessage(json);

await sender.SendMessageAsync(message);

Receiver side:

Console.WriteLine(message.Body.ToString());

Output:

{
  "OrderId": 101,
  "UserId": 50,
  "Amount": 500
}

Properties of ServiceBusMessage

You can add extra info:

var message = new ServiceBusMessage("OrderPlaced")
{
Subject = "NewOrder",
MessageId = Guid.NewGuid().ToString()
};

Common properties:

1. MessageId
Unique ID.

MessageId = "123"

Used to avoid duplicate processing.

1. Subject

Type/title of message.

Subject = "PaymentSuccess"

1. ApplicationProperties

Custom properties.

message.ApplicationProperties.Add("Priority", "High");

Example:

Priority = High

Simple example:

Courier service ��

Box = ServiceBusMessage

Inside box = message body

Label on box = properties (MessageId, Subject)

Courier boy = Sender

Receiver opens box and reads message.

service bus or api gateway

Show moreShow less

Both are used in microservices, but for different purposes.

Think simple:

· API Gateway → handles HTTP/API requests

· Service Bus → handles messages/events

API Gateway

It is the single entry point for client apps.

Example:

Mobile app calls:

/api/orders
/api/payment
/api/profile

Instead of calling all services directly:

Mobile App → API Gateway → Order Service
→ Payment Service
→ User Service

Why use it?

✅ Authentication
✅ Routing
✅ Rate Limiting
✅ Logging
✅ Load balancing

Real example:

Microsoft Azure API Management, Amazon API Gateway.

Service Bus

Used for async communication between services.

Example:

Order Service → Service Bus → Payment Service
→ Email Service

Why use it?

✅ Loose coupling
✅ Retry if service down
✅ Queue messages
✅ Event-driven communication

Real example:

Azure Service Bus, RabbitMQ, Apache Kafka

Real-time Example

Amazon order system:

Step 1: Client request

Mobile App → API Gateway → Order Service

User places order.

Step 2: Internal processing

Order Service publishes event:

OrderPlaced → Service Bus

Then:

· Payment Service

· Inventory Service

· Notification Service

process it.

So:

API Gateway = outside communication
Service Bus = inside communication

Interview answer:

API Gateway is used as a single entry point for client requests, while Service Bus is used for asynchronous communication between internal micro-services.

*************************************************************************************************************************************How .NET Code Executes

1. Write C# Code
Example:

Console.WriteLine("Hello");

1. Compilation
C# compiler (csc) compiles code into IL (Intermediate Language / MSIL / CIL).

.cs file → .exe / .dll

1. Assembly Creation
Compiled file contains:

· IL Code

· Metadata

· Manifest

1. CLR Loads Assembly
CLR (Common Language Runtime) loads the assembly into memory.

CLR handles:

· Memory Management

· Exception Handling

· Security

· Garbage Collection

1. JIT Compilation
JIT (Just-In-Time Compiler) converts IL code into native machine code at runtime.

IL → Native Code

1. CPU Executes Native Code
The CPU executes the machine code and produces output.

Flow Diagram

C# Code → Compiler → IL Code → CLR → JIT → Machine Code → CPU → Output

Interview one-line answer:

In .NET, C# code is compiled into IL, CLR loads it, JIT converts IL into machine code, and then CPU executes it.

-----------------------------------------------------------------------

Throttling in microservices means limiting the number of requests a client or service can make in a certain time.

Purpose:

· protect system from overload

· prevent abuse / spam

· avoid server crash

· ensure fair usage

Example:

Your API allows:

100 requests per minute

If client sends 101st request:

429 Too Many Requests

Real-time Example

Imagine a login API:

POST /api/login

Without throttling:

A bot can send 10,000 requests/sec ❌

Server may crash.

With throttling:

5 requests/minute per IP

Now system is safe.

In Microservices

Example:

Client → API Gateway → Order Service → Payment Service

If too many requests come:

Payment service may fail.

So apply throttling at:

· API Gateway

· individual microservice

· user/IP level

Types of Throttling

1. IP-based
Limit per IP.

Example:

192.168.1.1 → 100 req/min

1. User-based
Limit per user/token.

Example:

User A → 50 req/min

1. Service-based
Limit per service.

Example:

Payment API only:

20 req/sec

1. Global throttling
Whole application limit.

Common Algorithms

1. Fixed Window
Example:

100 req/min

resets every minute.

1. Sliding Window
More accurate.

1. Token Bucket
Tokens are added gradually.

1. Leaky Bucket
Processes requests at fixed speed.

In .NET Example

In ASP.NET Core:

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("fixed", config =>
    {
        config.PermitLimit = 100;
        config.Window = TimeSpan.FromMinutes(1);
    });
});

Use:

app.UseRateLimiter();

Interview answer:

Throttling in microservices is used to limit request rates to protect services from overload, abuse, and ensure fair usage. It is commonly implemented at API Gateway or service level using algorithms like Fixed Window, Sliding Window, or Token Bucket.

Ocelot is an API Gateway library for .NET.

It is used in microservices to act as a single entry point for all client requests.

Example:

Without Ocelot:

Client → Order Service
Client → Payment Service
Client → User Service

Client must know all URLs.

With Ocelot:

Client → Ocelot API Gateway → Order Service
→ Payment Service
→ User Service

Now client calls only one URL.

Why use Ocelot?

It provides:

✅ Routing
✅ Authentication
✅ Authorization
✅ Rate Limiting / Throttling
✅ Load Balancing
✅ Caching
✅ Request aggregation

Real-time Example

E-commerce app:

Frontend calls:

https://api.myapp.com/orders

Ocelot routes to:

http://orderservice/api/orders

Installation

dotnet add package Ocelot

ocelot.json

Example config:

{
  "Routes": [
    {
      "UpstreamPathTemplate": "/orders",
      "UpstreamHttpMethod": [ "GET" ],
      "DownstreamPathTemplate": "/api/orders",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5001
        }
      ]
    }
  ],
  "GlobalConfiguration": {
    "BaseUrl": "https://localhost:5000"
  }
}

Meaning:

Client hits /orders
↓
Forward to localhost:5001/api/orders

Program.cs

builder.Configuration.AddJsonFile("ocelot.json");

builder.Services.AddOcelot();

var app = builder.Build();

await app.UseOcelot();

Interview Answer:

Ocelot is an open-source API Gateway for .NET used in microservices architecture to provide routing, authentication, rate limiting, caching, and load balancing as a single entry point for client requests.

common open-source API Gateways used in microservices architecture, especially useful for .NET developers:

1. Ocelot

2. YARP (Yet Another Reverse Proxy)

Built by Microsoft.

Modern reverse proxy / API gateway for .NET.

Features:

· High performance

· Reverse proxy

· Load balancing

· Session affinity

· Health checks

Best for:

✅ custom API gateway in .NET

Example:

Client → YARP → Services

3. Kong Gateway

Very popular open-source gateway.

Built on NGINX.

Features:

· Plugins

· JWT auth

· OAuth2

· Logging

· Rate limiting

Best for:

✅ enterprise / cloud-native systems

4. NGINX

Used as reverse proxy and lightweight API gateway.

Features:

· Reverse proxy

· SSL termination

· Load balancing

· Caching

Best for:

✅ simple routing and proxy

5. Apache APISIX

Cloud-native API gateway.

Features:

· Dynamic routing

· Authentication

· Observability

· Traffic control

Best for:

✅ Kubernetes / cloud-native apps

6. Tyk

Open-source API gateway and API management.

Features:

· Security

· Analytics

· Developer portal

· Rate limiting

7. KrakenD

High-performance API gateway.

Features:

· Aggregation

· Transformation

· Low latency

Best for:

✅ high-speed APIs

8. Traefik

Popular with Docker / Kubernetes.

Features:

· Service discovery

· SSL

· Load balancing

9. Envoy Proxy

Modern cloud-native proxy.

Features:

· gRPC support

· observability

· service mesh integration

Used with:

Istio

10. HAProxy

Primarily load balancer, can act as gateway.

For .NET interviews, mostly they ask:

1. Ocelot

2. YARP

3. NGINX

4. Kong

Best answer in interview:

In .NET microservices, commonly used API gateways are Ocelot and YARP for .NET-based systems, while Kong, NGINX, and Envoy are popular for enterprise and cloud-native environments.

YARP (Yet Another Reverse Proxy) is a modern reverse proxy / API gateway built by Microsoft for ASP.NET Core.

Simple meaning:

It sits between client and microservices.

Client → YARP → Microservices

Example:

Client → YARP → Order Service
→ Payment Service
→ User Service

Instead of exposing many service URLs, client calls only YARP.

Why use YARP?

· Routing → forwards request to correct service

· Load Balancing → distribute traffic

· Health Checks → skip unhealthy servers

· SSL Termination → handle HTTPS

· Session Affinity → same user to same server

· High Performance

Install

dotnet add package Yarp.ReverseProxy

Basic setup

builder.Services
.AddReverseProxy()
.LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

var app = builder.Build();

app.MapReverseProxy();

app.Run();

appsettings.json

{
  "ReverseProxy": {
    "Routes": {
      "ordersRoute": {
        "ClusterId": "ordersCluster",
        "Match": {
          "Path": "/orders/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "ordersCluster": {
        "Destinations": {
          "d1": {
            "Address": "https://localhost:5001/"
          }
        }
      }
    }
  }
}

Now:

/api/orders → forwarded to Order Service

YARP vs Ocelot

Feature	YARP	Ocelot
Built by	Microsoft	Community
Performance	Very high	Good
Reverse proxy	Strong	Medium
API Gateway features	Less built-in	More built-in
Customization	High	Easy

When to use?

Use YARP when:

✅ You need high-performance proxy
✅ You want custom gateway logic
✅ You are using .NET ecosystem

Interview answer:

YARP is Microsoft’s high-performance reverse proxy for ASP.NET Core used for request routing, load balancing, and acting as an API gateway in microservices.

which case we use yarp or ocelot and why ?

Both YARP and Ocelot are used in microservices, but the use case is different.

Simple rule:

· YARP → when you need a high-performance reverse proxy with custom logic

· Ocelot → when you need an easy API Gateway with built-in features

Use Ocelot when…

You want quick API Gateway setup.

Example:

Client → Ocelot → Order Service
→ Payment Service

Why?

Because Ocelot already provides:

✅ Routing
✅ Authentication
✅ Authorization
✅ Rate limiting
✅ Caching
✅ Request aggregation

Minimal coding.

Example use case:

E-commerce project with 5–10 microservices.

You need:

· JWT auth

· route mapping

· throttling

Ocelot is faster to implement.

Use YARP when…

You need more control and performance.

Example:

Client → YARP → Services

Why?

YARP is strong in:

✅ High performance
✅ Reverse proxy
✅ Load balancing
✅ Health checks
✅ Session affinity
✅ custom transformations

Example use case:

Large-scale application with heavy traffic.

Like:

· banking system

· stock trading app

· high-load APIs

YARP handles more traffic better.

Real-world Example

Ocelot case:

Food delivery app:

Mobile App → Ocelot → User Service
→ Order Service
→ Payment Service

Need easy gateway.

Use Ocelot.

YARP case:

Netflix-like streaming system:

Millions of requests.

Need:

· routing

· load balancing

· health checks

· custom proxy rules

Use YARP.

Interview Answer:

Use Ocelot when you need a quick API Gateway solution with built-in features like authentication, rate limiting, and routing. Use YARP when you need a high-performance reverse proxy with more flexibility, custom logic, and better scalability.

what is reverse proxy means in above question

A reverse proxy is a server that sits in front of your backend services and forwards client requests to them.

Simple flow:

Client → Reverse Proxy → Backend Server

The client talks only to the proxy, not directly to the backend.

Real-time example

Without reverse proxy:

Client → Order Service
Client → Payment Service
Client → User Service

Client must know all service URLs.

Example:

api-order.com
api-payment.com
api-user.com

Hard to manage.

With reverse proxy:

Client → YARP/NGINX → Order Service
→ Payment Service
→ User Service

Client calls only one URL:

api.myapp.com

Proxy decides where to send request.

Example:

/orders → Order Service
/payment → Payment Service

Why use reverse proxy?

1. Hide backend services

Client cannot directly access services.

1. Load balancing

Client → Proxy → Server1
→ Server2

Traffic distributed.

1. SSL termination

Proxy handles HTTPS.

Backend can use HTTP internally.

1. Security

Can apply:

· authentication

· rate limiting

· firewall rules

1. Health checks

If one service is down:

skip failed server

Reverse Proxy vs Forward Proxy

Forward Proxy

Works for client.

Example:

Client → Proxy → Internet

Used in office networks.

Reverse Proxy

Works for server.

Example:

Client → Proxy → Server

Used in microservices.

In your previous question:

YARP is mainly a reverse proxy.

Ocelot is more of an API Gateway.

Interview answer:

A reverse proxy is an intermediary server that receives client requests and forwards them to backend servers, providing routing, load balancing, security, and SSL termination.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Rate Limiting:

Think of rate limiting as a “traffic control system” for your API.

�� Real-Time Example: Food Delivery App

Imagine you’re using Swiggy or Zomato.

Scenario:

You search for “pizza” multiple times very quickly.

Without Rate Limiting:

You (or a bot) send 1000 requests in 10 seconds

Server gets overloaded ��

App becomes slow or crashes for everyone

With Rate Limiting:

The system says:

“You can only make 10 requests per minute”

So if you exceed that:

You get an error like:

429 Too Many Requests

Or a message: “Try again after some time”

�� Common Types of Rate Limiting

Fixed Window → 100 requests/minute

Sliding Window → smoother control

Token Bucket → flexible burst handling

�� Why It’s Important

Prevents server overload

Improves API stability

Protects against bots & attacks

Ensures fair usage for all users

�� What is Fixed Window?

��
“You can do X actions in a fixed time block, then it resets.”

“Fixed window rate limiting allows a fixed number of requests in a set time period, and resets the count when the time window ends.”

�� Fixed window = office timing

· Office open: 9 AM – 5 PM

· After 5 PM → closed

· Next day → reset

What is Sliding Window?

“System checks how many requests you made in the last X seconds (not fixed time blocks).”

How to secure web api response:
· HTTPS

· JWT

· Authorization

· DTO

· Least Privilege

· HTTPS enforce करता हूँ
ताकि data encrypted रहे और man-in-the-middle attacks avoid हों।

· Authentication implement करता हूँ (JWT/OAuth)
जिससे सिर्फ authenticated users ही API access कर सकें।

· Authorization apply करता हूँ
Role-based या policy-based access control use करके ensure करता हूँ कि user सिर्फ permitted data ही देख सके।

· DTO (Data Transfer Object) use करता हूँ
Direct database entities return नहीं करता, ताकि sensitive fields expose न हों।

· Sensitive data hide करता हूँ
जैसे password, tokens, internal IDs, audit fields आदि response में नहीं भेजता।

· Principle of Least Privilege follow करता हूँ
Client को सिर्फ उतना ही data देता हूँ जितना जरूरी है—no extra exposure।

· Security headers add करता हूँ
जैसे X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, ताकि XSS और clickjacking attacks prevent हों।

· Proper error handling करता हूँ
Client को generic error message देता हूँ और detailed logs server-side रखता हूँ।

· Rate limiting और throttling apply करता हूँ
ताकि API abuse और brute-force attacks prevent हो सकें।

· Logging और monitoring implement करता हूँ
Suspicious activity track करने के लिए।

Essential Microservices Interview Questions You Must Know

Micro Services

1. Basics (Detailed Answers)

❓ What are Micro-services?

❓ Difference: Monolith vs Micro services

❓ Advantages of Micro services

✅ 1. Independent Deployment

✅ 2. Scalability

✅ 3. Fault Isolation

✅ 4. Technology Flexibility

✅ 5. Faster Development (for large teams)

❌ Disadvantages of Micro services

❌ 1. Complexity

❌ 2. Network Overhead

❌ 3. Data Consistency Issues

❌ 4. Debugging Difficulty

❌ 5. DevOps Requirement

❓ When should you NOT use Microservices?

❌ Avoid Microservices when:

❓ SOA vs Microservices

❓ What is a Bounded Context?

⚙️

2. Core Concepts (Detailed Answers)

❓ What is API Gateway? Why is it used?

✅ Why use API Gateway?

�� Example:

�� One-liner:

❓ What is Service Discovery?

�� Types:

�� Example tools:

�� One-liner:

❓ What is Load Balancing?

�� Types:

�� Example:

�� Benefits:

�� One-liner:

❓ What is Circuit Breaker Pattern?

�� Problem:

�� Solution:

�� States:

�� Example:

�� One-liner:

❓ What is Configuration Management?

�� Examples:

�� Tools:

�� Benefits:

�� One-liner:

❓ What is Distributed Logging?

�� Problem:

�� Solution:

�� Tools:

�� Benefits:

�� One-liner:

�� 3. Communication Between Services

❓ Synchronous vs Asynchronous Communication

�� Synchronous Communication

✅ Pros:

❌ Cons:

�� Asynchronous Communication

✅ Pros:

❌ Cons:

�� One-liner:

❓ REST vs Messaging (Queue-based systems)

�� REST (HTTP-based)

✅ Pros:

❌ Cons:

�� Messaging (Queue-based)

✅ Pros:

❌ Cons:

�� One-liner:

❓ What is Event-Driven Architecture?

�� Flow:

�� Benefits:

�� One-liner:

❓ What is a Message Broker?

�� Responsibilities:

�� Examples:

�� Example:

�� One-liner:

❓ How do microservices communicate securely?