Cancellation and refund policy in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding core components of a cancellation and refund system

Which component is essential for tracking user cancellation requests in a cancellation and refund policy system?

A User Authentication Module

B Payment Gateway Integration

C Cancellation Request Handler

D Notification Service

💡 Hint

Think about which part directly manages the cancellation actions initiated by users.

The Cancellation Request Handler is the core component that processes and tracks cancellation requests from users, making it essential for the system.

❓ Architecture

intermediate

Designing a scalable refund processing flow

Which architecture pattern best supports scalable and asynchronous refund processing in a cancellation and refund policy system?

A Event-driven microservices with message queues

B Monolithic synchronous API calls

C Direct database triggers for refund updates

D Client-side refund calculation

💡 Hint

Consider how to handle many refund requests without blocking the system.

Event-driven microservices with message queues allow refund requests to be processed asynchronously and scale independently, improving system responsiveness and reliability.

❓ scaling

advanced

Handling peak loads in cancellation requests

During a major sale, cancellation requests spike 10x. Which approach best ensures system stability under this load?

A Increase database write capacity only

B Implement rate limiting and queue requests for processing

C Process all requests synchronously to avoid backlog

D Disable cancellation temporarily

💡 Hint

Think about controlling request flow to prevent overload.

Rate limiting combined with queuing smooths out spikes, preventing system overload and ensuring stable processing of cancellation requests.

❓ tradeoff

advanced

Choosing refund timing strategies

Which refund timing strategy balances user satisfaction and operational cost best?

A Refunds processed after 7 days delay automatically

B Instant refunds processed immediately

C Refunds processed only after manual review

D Batch refunds processed once daily

💡 Hint

Consider a delay that allows fraud checks but does not frustrate users too much.

Processing refunds automatically after a short delay (e.g., 7 days) allows time for verification while maintaining reasonable user satisfaction and controlling operational costs.

❓ estimation

expert

Estimating refund system capacity

Your platform has 1 million active users. On average, 2% request cancellations monthly, and 80% of those require refunds. Each refund request takes 500ms to process. What is the minimum number of concurrent refund processing workers needed to handle peak load assuming all requests come in a 1-hour window?

A Approximately 1480 workers

B Approximately 222 workers

C Approximately 444 workers

D Approximately 740 workers

💡 Hint

Calculate total refund requests, then divide total processing time by available time.

Total users: 1,000,000
Monthly cancellations: 2% → 20,000
Refunds needed: 80% of 20,000 → 16,000
Each refund takes 0.5 seconds
Total processing time: 16,000 * 0.5 = 8,000 seconds
Peak window: 1 hour = 3600 seconds
Workers needed = 8,000 / 3,600 ≈ 2.22 → multiply by concurrency factor → ~740 workers to handle overhead and parallelism.