Notes Microservies Implementation BFSI Case study

Q1. What is a Service Mesh and why use Istio in BFSI microservices?

Step-by-step explanation

1. Definition

   • A Service Mesh is an infrastructure layer that manages service-to-service communication (east-west traffic) in a microservices ecosystem.

   • Istio implements this using sidecar proxies (Envoy) that intercept traffic, enabling security, observability, and traffic control without changing application code.

2. Core Features of Istio

   • mTLS (mutual TLS): Encrypts internal traffic (PCI DSS/RBI compliance).

   • Traffic management: Canary releases, A/B testing, failover.

   • Observability: Distributed tracing, metrics, logs across microservices.

   • Fault tolerance: Retries, circuit breaking, rate limiting.

3. Why BFSI Needs It

   • BFSI platforms (loan, mutual fund, wallet) must secure internal APIs (e.g., Loan ↔ Credit Score).

   • Regulatory mandates require end-to-end encryption and auditable traffic routing.

   • Enables zero downtime deployments — crucial during trading/transaction windows.

4. Example: Loan Processing Platform

   • Microservices: KYC, Credit Score, Loan Evaluation, Fraud Check, Disbursement.

   • Istio secures and manages communication:

     • KYC ↔ Credit Score: mTLS enforced

     • Traffic split: 90% to Loan Evaluation v1, 10% to v2 during rollout.

Text Diagram:

scss

CopyEdit

[API Gateway] → [Istio Ingress] → [KYC | Credit | Loan | Fraud] (Each service has Envoy proxy → mTLS, telemetry, retries)

Q2. How does Istio enable zero-downtime deployments in BFSI apps?

Step-by-step explanation

1. Canary Deployment with Istio

   • Deploy v2 alongside v1 in the same mesh

   • Use VirtualService to route 5% traffic to v2, 95% to v1 initially

2. Monitor Metrics

   • Use Prometheus/Grafana dashboards (latency, error rate)

   • Example: Loan evaluation v2 introduces new scoring model — watch approval rate and error patterns.

3. Gradual Rollout

   • Incrementally increase v2 traffic (20% → 50% → 100%)

   • Rollback instantly if SLA breaches occur

4. Why BFSI Needs It

   • Trading apps and loan disbursement cannot afford downtime

   • Canary ensures safe rollout during live financial transactions

Q3. What API Gateway patterns are best for BFSI microservices?

Step-by-step explanation

1. API Gateway Role

   • Entry point for client traffic (mobile, web)

   • Functions: routing, authentication, throttling, transformation

2. Patterns

   • Aggregator Pattern: Combine responses from multiple services (e.g., Portfolio + NAV)

   • Proxy Pattern: Direct requests to a specific service (e.g., /loan → Loan Service)

   • Backend-for-Frontend (BFF): Separate gateways for mobile vs web

   • Security Enforcement: JWT validation, OAuth2 flows

3. Azure Implementation

   • Azure API Management (APIM) + Azure Front Door:

     • Global routing

     • JWT validation

     • Caching for static responses (e.g., fund NAVs)

4. BFSI Example

   • Mutual Fund App:

     • API Gateway aggregates: NAV Service + Portfolio Service + Compliance Service → single API /dashboard

Q4. Why is Redis caching essential for BFSI microservices?

Step-by-step explanation

1. Problem in BFSI apps

   • Frequent lookups (e.g., credit score, NAV, loan eligibility)

   • High DB load during spikes (e.g., market opening)

2. Redis Benefits

   • Sub-millisecond latency

   • In-memory store → fast reads/writes

   • Supports TTL (Time-To-Live) for expiring sensitive data

3. Caching Patterns

   • Cache-aside (lazy loading): Fetch → Cache → Return

   • Write-through: Cache updated alongside DB write

   • Write-behind: Cache first → async DB write

4. BFSI Example

   • Loan Evaluation Service caches credit score results for 5 minutes

   • Reduces API calls to third-party credit bureau → cost and latency savings

Q5. How do you handle cache invalidation in BFSI scenarios?

Step-by-step explanation

1. Why it’s critical

   • Stale data can lead to wrong loan approvals or outdated NAV values

2. Strategies

   • TTL-based invalidation: Expire credit score after 5 minutes

   • Event-driven invalidation: On LoanApproved Kafka event → purge Redis key credit:user123

   • Versioned keys: During rollout (v1 vs v2) → keys like loan:v2:user123

3. BFSI Example

   • Mutual Fund NAV updates every 15 min → Redis TTL = 15 min

   • On NAV recalculation event → proactively invalidate cache

Q6. Explain Event Sourcing and CQRS with BFSI use case

Step-by-step explanation

1. Event Sourcing

   • Store events (state changes) rather than final state

   • Example: LoanApplied, LoanApproved, LoanDisbursed

2. CQRS (Command Query Responsibility Segregation)

   • Separate write model (commands) and read model (queries)

   • Optimize reads for reporting dashboards (denormalized views)

3. BFSI Example

   • Digital Wallet:

     • Event Sourcing: Full audit of wallet transactions (RBI audit compliance)

     • CQRS: Separate read replica for fast transaction history queries on mobile app

Q7. How do you achieve zero downtime deployments in BFSI apps?

Step-by-step explanation

1. Blue-Green Deployment

   • Maintain two environments (Blue = active, Green = idle)

   • Deploy to Green → test → switch traffic

   • Rollback by switching back to Blue

2. Canary Release with Istio

   • Gradually route traffic to new version

   • Example: New loan scoring algorithm → test on 5% traffic first

3. Rolling Updates

   • Kubernetes updates pods one at a time

   • Suitable for non-critical BFSI services

Q8. How do you ensure PCI DSS, GDPR, and RBI compliance in microservices?

Step-by-step explanation

1. PCI DSS (Card Data)

   • Tokenize PAN → never store raw card data

   • Enforce TLS 1.2+ and mTLS between services

2. GDPR (Data Privacy)

   • Right to erasure (delete PII across all services)

   • Data minimization (only store needed info)

3. RBI/SEBI (India BFSI)

   • Data localization → Azure India regions

   • Immutable audit logs (event sourcing) for 7-year retention

4. BFSI Example

   • Mutual fund platform: NAV data + customer PII stored locally in India

   • Audit logs for all trades → WORM (Write Once Read Many) compliant storage

Q9. How do you design multi-tenant BFSI microservices (SaaS for banks)?

Step-by-step explanation

1. Multi-tenancy Patterns

   • Database per tenant: Strong isolation (best for BFSI regulatory needs)

   • Schema per tenant: Shared DB, separate schemas

   • Row-level multi-tenancy: Cheapest, least isolation

2. BFSI Implementation

   • Digital Wallet serving HDFC, ICICI:

     • Separate schemas per bank → isolation + easier reporting

3. Challenges

   • Data migration (tenant onboarding/offboarding)

   • Tenant-specific configurations (limits, compliance rules)

Q10. How do you scale BFSI microservices using KEDA (event-driven scaling)?

Step-by-step explanation

1. Problem

   • BFSI workloads are spiky (e.g., UPI during Diwali sales)

   • Need event-driven scaling vs CPU-based scaling

2. KEDA Solution

   • KEDA monitors Kafka/Event Hub lag → auto-scales consumers

   • Scale down to 0 pods when idle (cost saving)

3. BFSI Example

   • Fraud detection service scales from 2 pods → 50 pods when Kafka queue length > 1000 (during festival transaction spikes)

Q11. How do you handle distributed transactions without 2PC in BFSI?

Step-by-step explanation

1. Problem

2. BFSI workflows (e.g., loan approval) span multiple services:

   • KYC → Credit Score → Loan Evaluation → Disbursement

3. Two-phase commit (2PC) is impractical (performance, locking, failure risks).

4. Solution – Eventual Consistency via Saga + Outbox Pattern

5. Each service emits domain events after local transaction commit.

6. Outbox Pattern:

   • Write event to outbox table in same DB transaction

   • A background process publishes events to Kafka

7. Saga Pattern:

   • Orchestrates sequence, handles compensating transactions (rollback if failure).

8. BFSI Example: Loan Processing

9. LoanApplied → KYC Service processes → emits KYCCompleted

10. KYCCompleted → Credit Service → emits CreditChecked

11. If credit fails, Saga triggers compensation: mark loan as rejected, refund processing fees.

12. Benefits

13. Avoids distributed locks

14. Complies with audit requirements (every step logged)

15. Scales horizontally (no central transaction manager)

Q12. How do you ensure resilience and fault tolerance in BFSI microservices?

Step-by-step explanation

1. Challenges

2. Network failures, slow third-party APIs (e.g., credit bureau)

3. High availability required (e.g., 24x7 UPI, loan disbursement)

4. Techniques

5. Circuit Breakers: (Resilience4j/Istio) – prevent cascading failures

6. Retries with backoff: Controlled retries to avoid overload

7. Bulkhead Pattern: Isolate resources per service (thread pools)

8. Fallbacks: Graceful degradation (e.g., manual review if credit API fails)

9. BFSI Example

10. Fraud Detection API fails → Loan flow switches to manual approval queue

11. Istio detects failure → reroutes traffic to secondary fraud service (active-active DR)

Q13. How do you implement observability in BFSI microservices?

Step-by-step explanation

1. Observability Pillars

2. Logging: Centralized ELK stack (audit + debugging)

3. Metrics: Prometheus/Grafana (loan approval latency, transaction throughput)

4. Tracing: OpenTelemetry + Jaeger (trace KYC → Credit → Loan → Disbursement)

5. Correlation IDs

6. Unique ID per transaction (loanId)

7. Passed via headers across services (X-Correlation-ID)

8. BFSI Example

9. Mutual fund order trace:

   • OrderService → PaymentService → NAVService

   • Single trace spans all services for audit and performance analysis

Q14. How do you implement API rate limiting for BFSI customers?

Step-by-step explanation

1. Why needed

2. Prevent API abuse/fraud (e.g., excessive OTP requests)

3. Ensure fair usage among customers

4. Techniques

5. API Gateway (Azure APIM) policy: 1000 requests/min per client

6. Redis sliding window counters: Store request count per client key

7. BFSI Example

8. UPI Payment API:

   • Limit 10 OTP requests/hour per user

   • Exceed → block & alert fraud monitoring

Q15. How do you handle API versioning in BFSI systems?

Step-by-step explanation

1. Why versioning

2. Avoid breaking changes for existing clients

3. Support gradual migration to new features

4. Strategies

5. URI-based: /v1/loan, /v2/loan

6. Header-based: X-API-Version: 2

7. Backward-compatible JSON (optional fields)

8. BFSI Example

9. Loan API v1 returns basic status

10. Loan API v2 adds credit score + fraud flags

Q16. How do you enforce zero-trust security (mTLS + RBAC) in BFSI?

Step-by-step explanation

1. Zero Trust Principle

2. No implicit trust (even inside VPC)

3. Every call must authenticate & authorize

4. Implementation with Istio

5. mTLS: Encrypts service-to-service traffic

6. RBAC policies: Define which service can call which (e.g., Fraud → Credit Score allowed; Portfolio → Loan not allowed)

7. BFSI Example

8. Credit Service only accepts calls from Loan Service (strict mTLS + RBAC)

9. Enforced at service mesh layer (no code changes)

Q17. How do you design BFSI microservices for hybrid/cloud-agnostic deployment?

Step-by-step explanation

1. Problem

2. BFSI often needs on-prem + cloud (regulatory + DR)

3. Solution

4. Use Kubernetes (portable) + Istio (portable)

5. Externalize configs (Spring Cloud Config, Vault)

6. Avoid cloud-specific APIs (e.g., use Kafka over cloud-native queues)

7. BFSI Example

8. Mutual Fund app runs on Azure India (prod) + AWS Singapore (DR)

9. Same Helm charts + Istio manifests → deploy anywhere

Q18. How do you implement compliance logging (RBI/SEBI)?

Step-by-step explanation

1. Requirements

2. Immutable, tamper-proof logs

3. Retention 7–10 years

4. Implementation

5. Event sourcing (append-only)

6. WORM storage (Azure Blob immutable policies)

7. Encrypt logs at rest + in transit

8. BFSI Example

9. Every NAV update logged as event

10. Exported nightly to cold storage (SEBI audit ready)

Q19. How do you mask PII (Aadhaar, PAN) in BFSI microservices?

Step-by-step explanation

1. PII Protection Requirements

2. Show masked data in logs/dashboards

3. Full data only in secure contexts (e.g., compliance export)

4. Techniques

5. Masking: XXXX-XXXX-1234

6. Tokenization: Replace with random token, map in secure vault

7. Logging filters: Auto-mask sensitive fields

8. BFSI Example

9. Loan service logs:

   • Instead of Aadhaar=123456789012

   • Log Aadhaar=XXXX-XXXX-9012

Q20. How do you manage Right to Erasure (GDPR/DPDP) in BFSI event sourcing?

Step-by-step explanation

1. Challenge

2. Event sourcing stores immutable history

3. Must still comply with “delete personal data” requests

4. Solutions

5. Soft delete: Replace PII with anonymized tokens in projections

6. Crypto-shredding: Encrypt PII; discard keys upon delete request

7. Events remain but become unreadable

8. BFSI Example

9. Customer closes mutual fund account:

   • Events remain for audit

   • PII encrypted; key destroyed → data anonymized

Q21. How do you apply Polyglot Persistence in BFSI microservices?

Step-by-Step Answer

1. Concept

   • Polyglot persistence = using different databases for different services based on workload.

   • BFSI apps deal with transactional (loans), analytical (portfolio trends), and real-time data (NAVs, fraud alerts).

2. Design

   • Each microservice chooses the optimal database:

     • LoanService → PostgreSQL (ACID)

     • FraudService → Cassandra (large write throughput)

     • NAVService → TimescaleDB (time-series NAV history)

     • Cache → Redis (fast reads)

3. Implementation

   • DB per service; no cross-service joins

   • Aggregate via APIs or event bus

   • Use CDC (Change Data Capture) for syncing across stores (e.g., Debezium + Kafka)

4. BFSI Example

   • Loan origination writes approvals to Postgres

   • Fraud events stored in Cassandra for large-scale anomaly analysis

   • NAV calculations stored in Timescale for portfolio projections

CTO Follow-up Questions

• Q: “How do you ensure data consistency across multiple DB types?”

• A: Use event-driven updates + eventual consistency; implement reconciliation jobs for critical financial records.

• Q: “How do you backup and recover polyglot databases in BFSI?”

• A: Automated backups per DB type; cross-DB DR plans; periodic consistency checks via reconciliation services.

Q22. How does Event-Driven Architecture benefit BFSI workflows?

Step-by-Step Answer

1. Concept

   • Microservices publish/subscribe to events instead of direct API calls.

   • Asynchronous → decoupled → scalable.

2. Benefits

   • BFSI flows (loan approval, mutual fund SIP) are naturally event-based.

   • Reduces tight coupling, supports real-time notifications.

3. Implementation

   • Use Kafka/Event Hub for event streaming.

   • Event schema registry (Avro/Protobuf) for version control.

4. BFSI Example

   • Loan lifecycle:

     • LoanApplied → triggers KYC check

     • KYCCompleted → triggers Credit Score check

     • LoanApproved → triggers Disbursement

CTO Follow-up Questions

• Q: “How do you ensure events aren’t lost (exactly-once delivery)?”

• A: Use Kafka transactions, idempotent consumers, and retries with DLQ.

• Q: “How do you audit event chains for RBI?”

• A: Persist all events in immutable event store; provide replay capability for audits.

Q23. How do you ensure idempotency in BFSI transactions?

Step-by-Step Answer

1. Problem

   • Duplicate events/requests can cause double debit or double disbursement.

2. Solution

   • Generate unique transactionId for each request.

   • Store processed IDs in Redis or DB.

   • Reject duplicates if ID already exists.

3. Implementation

   • Idempotency key in request header.

   • Expire keys after business window (e.g., 24 hrs).

4. BFSI Example

   • UPI payment service ignores duplicate “Pay ₹500” events using idempotency keys.

CTO Follow-up Questions

• Q: “Where do you store idempotency keys for horizontal scaling?”

• A: In a distributed store (Redis) accessible to all service replicas.

• Q: “How do you clean expired keys?”

• A: Set TTL on keys; Redis auto-evicts after expiry window.

Q24. How is JWT/OAuth2 used to secure BFSI APIs?

Step-by-Step Answer

1. Concept

   • JWT: Stateless token containing claims (user ID, roles).

   • OAuth2: Standard framework for delegated authorization.

2. Implementation

   • Identity Provider issues JWT.

   • API Gateway validates token before routing.

   • Claims define access (e.g., retail vs corporate customer).

3. BFSI Example

   • Mutual fund dashboard:

     • JWT includes portfolio ID.

     • Gateway enforces scope: read:portfolio, write:orders.

CTO Follow-up Questions

• Q: “How do you revoke tokens if fraud is detected?”

• A: Maintain token blacklist in Redis; check token against blacklist on each request.

• Q: “How do you secure JWT signing keys?”

• A: Store keys in HSM/Key Vault; rotate keys regularly and propagate via JWKS endpoints.

Q25. How do you implement distributed locking in BFSI workflows?

Step-by-Step Answer

1. Problem

   • Concurrent requests may trigger duplicate actions (e.g., double loan disbursement).

2. Solution

   • Use Redis SETNX for distributed locks.

   • Set expiry to prevent deadlocks.

   • Acquire → process → release.

3. BFSI Example

   • Lock on loanId before disbursement; ensures single payout.

CTO Follow-up Questions

• Q: “What if service crashes before releasing lock?”

• A: Lock expiry ensures auto-release; implement retry/backoff.

• Q: “Would you use Zookeeper over Redis?”

• A: Zookeeper for complex coordination (leader election); Redis sufficient for simple locks.

Q26. How do you handle Dead Letter Queues (DLQ) in BFSI?

Step-by-Step Answer

1. Concept

   • Messages that fail processing after retries go to DLQ for manual/automated handling.

2. Implementation

   • Kafka DLQ topics or Azure Event Hub secondary queues.

   • Monitor DLQ growth via Prometheus.

3. BFSI Example

   • Failed mutual fund SIP events due to invalid account number → DLQ for investigation.

CTO Follow-up Questions

• Q: “How do you prevent DLQ flooding during major outages?”

• A: Use rate-limiting and circuit breakers; prioritize recovery queue processing.

• Q: “How do you reprocess DLQ events safely?”

• A: Manual review + replay service that ensures idempotency before retry.

Q27. API Composition vs Choreography — which fits BFSI better?

Step-by-Step Answer

1. API Composition

   • Gateway aggregates responses from multiple microservices.

   • Ideal for dashboards (portfolio view, loan summary).

2. Choreography

   • Services emit events; no central coordinator.

   • Ideal for workflows (loan processing, SIP setup).

3. Hybrid

   • Use both: Composition for reads, Choreography for writes.

CTO Follow-up Questions

• Q: “When would you prefer orchestration instead of choreography?”

• A: Orchestration for long-running workflows requiring compensation (e.g., loan approval).

• Q: “How do you trace distributed workflows?”

• A: Use correlation IDs propagated across events; trace with Jaeger/OpenTelemetry.

Q28. How do you use feature flags during BFSI releases?

Step-by-Step Answer

1. Concept

   • Toggle features at runtime; enable gradual rollout or instant rollback.

2. Implementation

   • Central feature flag service (LaunchDarkly or custom DB).

   • Cache flags in Redis for performance.

3. BFSI Example

   • Roll out new loan scoring model for 5% users first; expand gradually.

CTO Follow-up Questions

• Q: “How do you audit feature flag changes?”

• A: Log every flag toggle with user ID/timestamp; store in immutable audit logs.

• Q: “Can misconfigured flags expose premium features to wrong customers?”

• A: Mitigate by adding user-role checks in feature flag logic + automated tests.

Q29. How do you manage distributed configuration in BFSI?

Step-by-Step Answer

1. Need

   • Different environments (Dev, UAT, Prod).

   • Multi-tenant (ICICI, HDFC).

2. Implementation

   • Centralized config service (Spring Cloud Config/Azure App Config).

   • Secrets in Key Vault (not in config repo).

   • Auto-refresh via message bus (Kafka).

3. BFSI Example

   • Loan rate slabs per bank stored centrally; fetched dynamically by LoanService.

CTO Follow-up Questions

• Q: “How do you handle tenant-specific overrides?”

• A: Hierarchical configs: base + tenant overlay; resolve via tenant ID at runtime.

• Q: “What’s your rollback plan if a bad config is pushed?”

• A: Version configs; instant rollback by reapplying previous version.

Q30. How does Blue-Green deployment ensure zero downtime in BFSI?

Step-by-Step Answer

1. Concept

   • Two environments: Blue (live), Green (staging).

   • Deploy to Green → test → switch traffic.

2. Benefits

   • Instant rollback (switch back to Blue).

   • No downtime during deployments.

3. BFSI Example

   • Mutual fund NAV calculation update deployed to Green after market hours; switched live next day.

CTO Follow-up Questions

• Q: “How do you handle DB schema migrations in Blue-Green?”

• A: Backward-compatible schema changes; dual-write phase until cutover.

• Q: “Do you prefer Blue-Green or Canary for BFSI?”

• A: Blue-Green for predictable cutovers; Canary for gradual rollout (e.g., retail vs corporate customers).

Q31. How do you handle high traffic scaling in BFSI (e.g., IPO day)?

Step-by-Step Answer

1. Problem

   • Sudden traffic spikes (IPO subscriptions, loan campaigns).

2. Solution

   • Use KEDA for event-driven autoscaling:

     • Scale microservices based on Kafka topic lag or queue depth.

3. BFSI Example

   • Mutual fund SIP processing auto-scales from 5 to 100 pods based on order queue size.

CTO Follow-up Questions

• Q: “How do you prevent over-scaling and cost overruns?”

• A: Set upper limits on pod count; implement predictive scaling based on historical trends.

Q32. How do you apply chaos engineering to BFSI microservices?

Step-by-Step Answer

1. Concept

   • Inject failures in controlled environments to test resilience.

2. Implementation

   • Tools: Chaos Mesh, Gremlin.

   • Scenarios: kill credit service pods, network latency, DB outages.

3. BFSI Example

   • Simulate credit bureau outage; verify loan flow degrades gracefully (manual review queue).

CTO Follow-up Questions

• Q: “How do you ensure chaos experiments don’t impact customers?”

• A: Run in staging; or in prod with feature flags + customer whitelisting.

Q33. REST vs GraphQL in BFSI APIs?

Step-by-Step Answer

1. REST

   • Simple, cacheable, mature.

   • Multiple endpoints (loan, portfolio).

2. GraphQL

   • Single endpoint; client decides data shape.

   • Ideal for mobile dashboards (customizable queries).

3. BFSI Example

   • Loan app dashboard fetches status + EMI + credit score in one GraphQL call.

CTO Follow-up Questions

• Q: “How do you enforce field-level security in GraphQL?”

• A: Authorization checks per resolver; schema-based access control.

Q34. How do you optimize BFSI microservices cost on cloud?

Step-by-Step Answer

1. Strategies

   • Rightsizing pods (HPA + KEDA).

   • Spot instances for non-critical workloads.

   • Serverless for batch jobs (e.g., nightly NAV updates).

2. BFSI Example

   • Fraud analytics moved to serverless, saving 30% cost.

CTO Follow-up Questions

• Q: “How do you balance cost savings vs compliance (e.g., DR)?**

• A: Keep critical services on reserved nodes; optimize others with spot instances.

Q35. How do you implement token lifecycle management (refresh, revoke) in BFSI?

Step-by-Step Answer

1. Concept

   • Short-lived access tokens; refresh tokens for renewal.

2. Implementation

   • Store refresh tokens securely (encrypted DB).

   • Revoke via blacklist (Redis) or rotation.

3. BFSI Example

   • Mutual fund login: 15-min access token, 30-day refresh token.

CTO Follow-up Questions

• Q: “How do you force log out all sessions after breach?”

• A: Rotate signing key; invalidate all tokens instantly.

Q36. How do you implement distributed tracing for BFSI audits?

Step-by-Step Answer

1. Concept

   • Trace single transaction across services (loan apply → credit → fraud → approval).

2. Implementation

   • OpenTelemetry + Jaeger.

   • Correlation ID in headers (propagated via Istio).

3. BFSI Example

   • Audit shows full lifecycle of SIP order (customer → payment → NAV → portfolio).

CTO Follow-up Questions

• Q: “How do you retain traces for 10 years for RBI audits?”

• A: Export traces to cold storage (WORM-enabled S3/Blob).

Q37. How do you manage secrets across BFSI microservices?

Step-by-Step Answer

1. Problem

   • API keys, DB passwords, signing keys must be secure.

2. Solution

   • Central vault (Azure Key Vault, HashiCorp Vault).

   • Rotate secrets periodically; inject via sidecars.

3. BFSI Example

   • Credit bureau API keys stored in Key Vault; services fetch via managed identity.

CTO Follow-up Questions

• Q: “How do you audit secret access?”

• A: Enable vault access logs; integrate with SIEM for anomaly detection.

Q38. How do you implement API monetization for BFSI partners?

Step-by-Step Answer

1. Concept

   • Expose APIs to partners; charge based on usage (e.g., credit score API).

2. Implementation

   • API Gateway with usage plans, throttling, billing integration.

3. BFSI Example

   • Partner fintech pays per 1,000 credit score lookups.

CTO Follow-up Questions

• Q: “How do you prevent abuse/fraud in monetized APIs?”

• A: Rate limiting + usage analytics + fraud detection triggers.

Q39. How do you ensure auditability and compliance across BFSI microservices?

Step-by-Step Answer

1. Techniques

   • Event sourcing (immutable log).

   • Centralized audit service (collects from all microservices).

   • Tamper-proof storage (WORM).

2. BFSI Example

   • Every NAV calculation event stored with timestamp + approver ID.

CTO Follow-up Questions

• Q: “How do you provide auditors selective access?”

• A: Read-only audit APIs; role-based scopes; redact PII where unnecessary.

Q40. How do you plan DR (Disaster Recovery) for BFSI microservices?

Step-by-Step Answer

1. Requirements

   • RTO (Recovery Time Objective): e.g., 1 hour.

   • RPO (Recovery Point Objective): e.g., 5 min.

2. Implementation

   • Active-active across regions (e.g., Azure India Central + South).

   • Event replication (Kafka MirrorMaker).

   • DB replication with geo-failover.

3. BFSI Example

   • Loan system auto-fails over to DR region during Mumbai DC outage.

CTO Follow-up Questions

• Q: “How do you test DR without affecting customers?”

• A: Conduct chaos/failover drills in off-peak; simulate traffic redirection using Istio.