Microservices I

1. Microservices Fundamentals

Q1. What are Microservices, and why are they used?

Step-by-step answer:

1. DefinitionMicroservices is an architectural style where applications are composed of loosely coupled, independently deployable services, each responsible for a single business capability.

2. Key Principles

   • Single Responsibility (Each service solves one business function, e.g., KYC, Loan Evaluation)

   • Loose Coupling (Services communicate via APIs or messaging)

   • Independent Deployment (Change one service without redeploying all)

3. Advantages

   • Scalability (scale KYC service independently of Payments)

   • Agility (faster feature delivery, CI/CD)

   • Resilience (failure in one service doesn’t crash entire system)

4. BFSI ExampleIn a digital lending platform, separate services: KYC, Credit Score, Loan Evaluation, and Disbursement. A spike in loan applications only scales those services, not the whole system.

2. Architecture & Design

Q2. How do you design a Microservices architecture for a banking platform?

Step-by-step approach:

1. Identify Domains (DDD)

   • Account Management, KYC, Payments, Loan Processing, Fraud Detection.

2. Define Boundaries

   • Each microservice = one bounded context (e.g., KYC Service, Credit Check Service).

3. Choose Communication Style

   • Sync: REST/gRPC for user-facing APIs

   • Async: Kafka/NATS/Event Hubs for events (e.g., "KYC Completed")

4. Data Strategy

   • Database per service (e.g., Azure SQL for loans, CosmosDB for logs)

   • Avoid direct DB sharing → use API or events

5. Security

   • API Gateway + OAuth2/OpenID (Azure AD)

   • Secrets in Azure Key Vault

6. Observability

   • Centralized logs (ELK), metrics (Prometheus + Grafana), tracing (Jaeger)

7. Deployment

   • Containers on AKS + Istio for service mesh

Diagram:

[ API Gateway ] → [ Loan Service ] → [ Credit Check Service ]

↓

[ Kafka Bus ]

↓

[ Fraud Service ]

3. Data Consistency

Q3. How do you handle transactions across multiple Microservices?

Answer:

• Problem: No distributed ACID transaction across microservices.

• Solution: Use Saga Pattern (choreography or orchestration).

Example: Loan Application

1. Loan Service creates “Loan Request”

2. Publishes event Loan.Request.Created → Kafka

3. KYC Service validates and publishes KYC.Completed

4. Credit Service evaluates score → publishes Credit.Approved

5. Loan Service completes workflow or compensates (e.g., cancel loan)

4. Inter-Service Communication

Q4. When do you use REST vs Messaging (Kafka/NATS)?

Step-by-step:

• Use REST/gRPC

  • Request/Response, low latency

  • Example: Fetch user profile

• Use Event/Messaging (Kafka, NATS)

  • Async workflows, decoupling

  • Example: LoanApproved event triggers Notification & Disbursement

• Hybrid Approach

  • REST for queries, Events for updates

5. Resilience & Fault Tolerance

Q5. How do you make Microservices fault-tolerant?

Techniques:

• Circuit Breaker (Resilience4j / Istio)

• Retries with backoff (Spring Retry)

• Bulkhead & Rate Limiting (Istio policies)

• Graceful degradation (fallback APIs)

Example:Credit Score API fails → Loan Service uses cached score or flags for manual review.

6. Security in Microservices

Q6. How do you secure Microservices?

Step-by-step:

1. API Gateway (Azure API Management)

2. Authentication (Azure AD / OAuth 2.0)

3. Authorization (JWT claims per service)

4. Secrets & Config in Azure Key Vault

5. Encrypt data in transit (TLS) & at rest

Real-life BFSI Example:

• Loan Service APIs protected via OAuth2 tokens from Azure AD B2C

• Secrets (DB credentials) stored in Azure Key Vault, rotated automatically.

7. CI/CD & DevOps

Q7. How do you set up CI/CD for Microservices on Azure?

Flow:

1. Code in GitHub/Azure Repos

2. Azure DevOps Pipeline → Build each microservice (Docker image)

3. Push images to Azure Container Registry (ACR)

4. Deploy to AKS (Kubernetes) via Helm charts

5. Canary/Blue-Green deployment using Istio

8. Observability

Q8. How do you implement logging, metrics, and tracing?

• Logging: Centralized with ELK (ElasticSearch + Logstash + Kibana)

• Metrics: Prometheus + Grafana (service health dashboards)

• Tracing: OpenTelemetry + Jaeger (trace request path across services)

Example:Trace “Loan Application ID 123” from API Gateway → KYC → Credit Score → Disbursement

9. Performance & Scalability

Q9. How do you scale Microservices?

• Horizontal Scaling: Replicate pods in AKS based on CPU/memory (HPA)

• Event-driven Scaling: Use KEDA to scale consumers based on Kafka lag

• Database Scaling: Read replicas, sharding

10. Real-World BFSI Scenarios

Q10. How would you modernize a legacy monolithic loan system to microservices?

Approach:

1. Strangler Fig Pattern: Gradually replace monolith parts with microservices

2. Domain Decomposition: Identify core domains (KYC, Loan, Credit, Payments)

3. Event-Driven Integration: Publish domain events to Kafka

4. Data Migration: Service-specific databases, avoid shared schemas

5. Incremental Deployment: Run microservices alongside monolith, cutover gradually

Extra Advanced Topics

• Service Mesh (Istio)

• API Gateway Patterns

• Distributed Caching (Redis)

• Event Sourcing vs CQRS

• Zero-downtime Deployments

• Security Compliance (PCI DSS, GDPR, RBI/SEBI)

1. Service Mesh (Istio)

Q1. What is a service mesh and why use Istio?

Answer:

Step-by-step:

1. Definition

   • Service mesh manages service-to-service communication (east-west traffic) with features like traffic control, observability, and security without code changes.

2. Why Istio?

   • Automatic sidecar injection (Envoy proxy)

   • Advanced traffic routing (A/B, Canary)

   • Built-in mTLS for secure communication

   • Policy enforcement (rate limiting, RBAC)

   • Observability (metrics, tracing)

3. BFSI Example

   • In a loan platform, Istio manages internal traffic between KYC, Credit, and Fraud Detection services with mutual TLS and zero-downtime deployment.

Q2. How does Istio handle traffic splitting during deployment?

Step-by-step:

1. Deploy v2 of Loan Service alongside v1

2. Create Istio VirtualService to route 10% traffic to v2 (Canary)

3. Gradually increase to 100% after validation

Q3. What problems does Istio solve that API Gateway doesn’t?

• API Gateway → north-south traffic (client to service)

• Istio → east-west traffic (service to service)

• Istio adds: mTLS, retries, circuit breakers, observability without touching code

2. API Gateway Patterns

Q1. What are API Gateway patterns in microservices?

Step-by-step:

1. Aggregator Pattern

   • API Gateway aggregates responses from multiple services

   • Example: Dashboard showing KYC + Loan + Credit Score in one response

2. Proxy / Routing Pattern

   • Gateway routes request to appropriate service

3. Backend-for-Frontend (BFF)

   • Separate gateway per UI (mobile vs web)

4. Security Enforcement

   • JWT validation, OAuth2, rate limiting

Q2. How do you implement API Gateway on Azure?

• Azure API Management for:

  • Central entry point

  • Throttling & caching

  • JWT/OAuth token validation

  • Transformations (protocol, schema)

• Combine with Azure Front Door for global load balancing

3. Distributed Caching (Redis)

Q1. Why use distributed cache in microservices?

Step-by-step:

• Reduce DB load → cache frequently accessed data (e.g., KYC verification status)

• Session storage in stateless services

• Rate limiting counters

• Pub/Sub messaging

Q2. How do you design caching strategy?

1. Cache-aside (lazy loading) → most common

2. Write-through → write to cache + DB simultaneously

3. Write-behind → write to cache first, flush later to DB

Q3. BFSI Example

• Cache frequently accessed user profiles in Redis

• TTL = 5 mins to ensure near real-time freshness

4. Event Sourcing vs CQRS

Q1. What is Event Sourcing?

• Store state as a series of events (e.g., LoanApplied, LoanApproved)

• Rebuild state by replaying events

Q2. What is CQRS?

• Separate Command (write) and Query (read) models

• Allows optimizing reads and writes independently

Q3. When to combine Event Sourcing + CQRS?

• High auditability (BFSI compliance: RBI/SEBI)

• Need for replaying state (fraud investigations)

• Scaling read-heavy workloads (queries on loan status)

5. Zero-Downtime Deployments

Q1. How to achieve zero-downtime deployments?

Techniques:

1. Blue-Green Deployment

   • Run two environments → switch traffic instantly

2. Canary Deployment

   • Gradually shift traffic to new version

3. Rolling Updates (Kubernetes HPA)

   • Incrementally replace pods

4. Feature Flags

   • Toggle features without redeploying

Q2. BFSI Example

• Deploy Loan Service v2 → Canary route 5% traffic

• Validate transactions → Gradually scale to 100%

• Rollback quickly if failures occur

6. Security Compliance (PCI DSS, GDPR, RBI/SEBI)

Q1. How do you ensure microservices comply with PCI DSS (payment data)?

Step-by-step:

• Tokenize card data (don’t store PAN directly)

• Encrypt at rest (AES-256) and in transit (TLS 1.2+)

• Role-based access control (least privilege)

• Regular vulnerability scans

Q2. How do you ensure GDPR compliance in microservices?

• Implement Right to Erasure (delete PII across services)

• Data Minimization (store only required data)

• Encrypt PII and maintain audit logs

Q3. How do you ensure RBI/SEBI compliance for BFSI?

• Data localization (store in India region)

• Strong audit trails (event sourcing helps)

• Regular reporting and anomaly detection

1. Service Mesh (Istio)

Q1. What is a service mesh and why use Istio?

Answer:

Step-by-step:

1. Definition

   • Service mesh manages service-to-service communication (east-west traffic) with features like traffic control, observability, and security without code changes.

2. Why Istio?

   • Automatic sidecar injection (Envoy proxy)

   • Advanced traffic routing (A/B, Canary)

   • Built-in mTLS for secure communication

   • Policy enforcement (rate limiting, RBAC)

   • Observability (metrics, tracing)

3. BFSI Example

   • In a loan platform, Istio manages internal traffic between KYC, Credit, and Fraud Detection services with mutual TLS and zero-downtime deployment.

Q2. How does Istio handle traffic splitting during deployment?

Step-by-step:

1. Deploy v2 of Loan Service alongside v1

2. Create Istio VirtualService to route 10% traffic to v2 (Canary)

3. Gradually increase to 100% after validation

Q3. What problems does Istio solve that API Gateway doesn’t?

• API Gateway → north-south traffic (client to service)

• Istio → east-west traffic (service to service)

• Istio adds: mTLS, retries, circuit breakers, observability without touching code

2. API Gateway Patterns

Q1. What are API Gateway patterns in microservices?

Step-by-step:

1. Aggregator Pattern

   • API Gateway aggregates responses from multiple services

   • Example: Dashboard showing KYC + Loan + Credit Score in one response

2. Proxy / Routing Pattern

   • Gateway routes request to appropriate service

3. Backend-for-Frontend (BFF)

   • Separate gateway per UI (mobile vs web)

4. Security Enforcement

   • JWT validation, OAuth2, rate limiting

Q2. How do you implement API Gateway on Azure?

• Azure API Management for:

  • Central entry point

  • Throttling & caching

  • JWT/OAuth token validation

  • Transformations (protocol, schema)

• Combine with Azure Front Door for global load balancing

3. Distributed Caching (Redis)

Q1. Why use distributed cache in microservices?

Step-by-step:

• Reduce DB load → cache frequently accessed data (e.g., KYC verification status)

• Session storage in stateless services

• Rate limiting counters

• Pub/Sub messaging

Q2. How do you design caching strategy?

1. Cache-aside (lazy loading) → most common

2. Write-through → write to cache + DB simultaneously

3. Write-behind → write to cache first, flush later to DB

Q3. BFSI Example

• Cache frequently accessed user profiles in Redis

• TTL = 5 mins to ensure near real-time freshness

4. Event Sourcing vs CQRS

Q1. What is Event Sourcing?

• Store state as a series of events (e.g., LoanApplied, LoanApproved)

• Rebuild state by replaying events

Q2. What is CQRS?

• Separate Command (write) and Query (read) models

• Allows optimizing reads and writes independently

Q3. When to combine Event Sourcing + CQRS?

• High auditability (BFSI compliance: RBI/SEBI)

• Need for replaying state (fraud investigations)

• Scaling read-heavy workloads (queries on loan status)

5. Zero-Downtime Deployments

Q1. How to achieve zero-downtime deployments?

Techniques:

1. Blue-Green Deployment

   • Run two environments → switch traffic instantly

2. Canary Deployment

   • Gradually shift traffic to new version

3. Rolling Updates (Kubernetes HPA)

   • Incrementally replace pods

4. Feature Flags

   • Toggle features without redeploying

Q2. BFSI Example

• Deploy Loan Service v2 → Canary route 5% traffic

• Validate transactions → Gradually scale to 100%

• Rollback quickly if failures occur

6. Security Compliance (PCI DSS, GDPR, RBI/SEBI)

Q1. How do you ensure microservices comply with PCI DSS (payment data)?

Step-by-step:

• Tokenize card data (don’t store PAN directly)

• Encrypt at rest (AES-256) and in transit (TLS 1.2+)

• Role-based access control (least privilege)

• Regular vulnerability scans

Q2. How do you ensure GDPR compliance in microservices?

• Implement Right to Erasure (delete PII across services)

• Data Minimization (store only required data)

• Encrypt PII and maintain audit logs

Q3. How do you ensure RBI/SEBI compliance for BFSI?

• Data localization (store in India region)

• Strong audit trails (event sourcing helps)

• Regular reporting and anomaly detection