Skip to content

Latest commit

 

History

History
193 lines (100 loc) · 4.61 KB

File metadata and controls

193 lines (100 loc) · 4.61 KB

Case Study 1: Payment Processing System

Q: Design a payment processing system using microservices that:

Accepts user payments via multiple channels (UPI, cards, net banking).

Ensures reliability and fault tolerance.

Integrates with 3rd party payment gateways.

Must be scalable to handle 50k TPS.

Answer Outline:

Services:

Payment Service → orchestrates payment workflow.

User Service → stores user details, KYC.

Transaction Service → maintains transaction history.

Notification Service → sends SMS/Email confirmations.

Settlement Service → reconciles with banks/gateways.

Architecture Decisions:

Async Processing: Use Kafka to buffer payment requests (avoids dropping under spikes).

Idempotency: Payment requests must be idempotent (unique transaction ID).

Resilience: Resilience4j for retries/circuit breakers when 3rd party fails.

Data: Event sourcing (Kafka + DB) → replayable audit trail.

Scalability: Kubernetes HPA + Redis cache for hot data.

Java Stack: Spring Boot + Spring Cloud + Kafka + Redis + PostgreSQL.

Case Study 2: E-Commerce Order Management

Q: How would you design an order management microservices system for an e-commerce platform like Amazon?

Answer Outline:

Services:

Order Service → accepts and manages orders.

Inventory Service → manages stock.

Payment Service → handles payments.

Shipping Service → shipment & tracking.

Notification Service → alerts customers.

Workflow (Saga Pattern):

Place Order → Reserve Inventory → Deduct Payment → Ship → Notify.

If payment fails → compensate (release inventory, cancel order).

Consistency: Eventual consistency via Saga (choreography or orchestration).

Tech: Spring Boot, Kafka, Postgres/MongoDB, ElasticSearch for search.

Scalability: Each service deployable independently on Kubernetes.

Case Study 3: Real-Time Stock Trading System

Q: Design a low-latency stock trading platform using microservices.

Answer Outline:

Services:

Market Data Service → consumes live stock feeds.

Order Matching Service → matches buy/sell orders (low latency critical).

Risk Management Service → validates credit/exposure limits.

Trade Service → persists trades.

Notification Service → confirms execution to users.

Key Considerations:

Ultra Low Latency: Use Java with Netty, LMAX Disruptor for event processing.

Messaging: Kafka for event streaming, but for ultra-low latency → Aeron/Chronicle Queue.

Fault Tolerance: Circuit breaker & fallback if risk service is unavailable.

Scalability: Horizontal scaling of Order Matching Service.

Data: In-memory caching (Hazelcast/Redis) for hot data.

Case Study 4: Online Video Streaming Platform

Q: How would you design a Netflix-like video streaming platform using microservices?

Answer Outline:

Services:

User Service → authentication, profiles.

Catalog Service → metadata about movies/shows.

Streaming Service → handles video delivery (CDN integration).

Recommendation Service → personalized suggestions (ML model).

Billing Service → subscription management.

Architecture Decisions:

API Gateway: To manage routing + authentication.

Resilience: Retry & circuit breaker when catalog service fails.

Caching: Redis/CDN edge caching for popular content.

Observability: Distributed tracing for latency bottlenecks.

Scalability: Streaming service uses Kubernetes + autoscaling.

Case Study 5: Banking Core System Modernization

Q: Your bank wants to modernize its monolithic core banking application into microservices. How would you approach this migration?

Answer Outline:

Step 1: Strangler Fig Pattern → gradually replace monolith modules with microservices.

Step 2: Domain-Driven Design (DDD):

Accounts Service.

Payments Service.

Loans Service.

Customer Service.

Step 3: Data Strategy:

Break large DB into schema-per-service.

Use CDC (Change Data Capture) + Kafka to sync.

Step 4: Security: Strict compliance (OAuth2, mTLS, PCI DSS).

Step 5: Deployment: Hybrid → monolith + microservices coexist until fully migrated.

Case Study 6: Fault Tolerant Travel Booking System

Q: Design a travel booking microservice system (Flights, Hotels, Payments). How do you handle failures?

Answer Outline:

Services:

Booking Service → orchestration.

Flight Service → airline availability.

Hotel Service → hotel inventory.

Payment Service → transactions.

Notification Service.

Challenges & Solutions:

Distributed transaction: Use Saga pattern.

Failure Handling: If hotel booking fails → roll back flight reservation.

Resilience: Retry with exponential backoff for flaky APIs.

Rate Limiting: Protect 3rd party APIs.

Observability: Central logging + tracing to debug failed bookings.