Bird
Raised Fist0
LLDsystem_design~20 mins

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

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Challenge - 5 Problems
🎖️
Cancellation and Refund Policy Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
2:00remaining
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?

AUser Authentication Module
BPayment Gateway Integration
CCancellation Request Handler
DNotification Service
Attempts:
2 left
💡 Hint

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

❓ Architecture
intermediate
2:00remaining
Designing a scalable refund processing flow

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

AEvent-driven microservices with message queues
BMonolithic synchronous API calls
CDirect database triggers for refund updates
DClient-side refund calculation
Attempts:
2 left
💡 Hint

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

❓ scaling
advanced
2:00remaining
Handling peak loads in cancellation requests

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

AIncrease database write capacity only
BImplement rate limiting and queue requests for processing
CProcess all requests synchronously to avoid backlog
DDisable cancellation temporarily
Attempts:
2 left
💡 Hint

Think about controlling request flow to prevent overload.

❓ tradeoff
advanced
2:00remaining
Choosing refund timing strategies

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

ARefunds processed after 7 days delay automatically
BInstant refunds processed immediately
CRefunds processed only after manual review
DBatch refunds processed once daily
Attempts:
2 left
💡 Hint

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

❓ estimation
expert
3:00remaining
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?

AApproximately 1480 workers
BApproximately 222 workers
CApproximately 444 workers
DApproximately 740 workers
Attempts:
2 left
💡 Hint

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

Practice

(1/5)
1. What is the primary purpose of a cancellation and refund policy in a system?
easy
A. To define rules for stopping services and returning money
B. To increase the price of products
C. To track user login times
D. To manage database backups

Solution

  1. Step 1: Understand the role of cancellation policies

    Cancellation and refund policies set clear rules about when and how users can stop services and get money back.

  2. Step 2: Eliminate unrelated options

    Options about pricing, login times, or backups do not relate to cancellation or refunds.

  3. Final Answer:

    To define rules for stopping services and returning money -> Option A

  4. Quick Check:

    Cancellation policy = service stop rules [OK]
Hint: Cancellation policies define service stop and refund rules [OK]
Common Mistakes:
  • Confusing cancellation policy with pricing strategy
  • Thinking it manages user authentication
  • Assuming it handles technical backups
2. Which of the following is a correct component to include in a cancellation policy data model?
easy
A. login_attempts: int
B. user_password: string
C. product_price: float
D. allowed_cancellation_time: datetime

Solution

  1. Step 1: Identify relevant data for cancellation policy

    The allowed cancellation time defines until when a user can cancel and get a refund.

  2. Step 2: Exclude unrelated fields

    User password, product price, and login attempts are unrelated to cancellation timing.

  3. Final Answer:

    allowed_cancellation_time: datetime -> Option D

  4. Quick Check:

    Cancellation policy needs cancellation time [OK]
Hint: Cancellation policy needs allowed cancellation time field [OK]
Common Mistakes:
  • Including unrelated user or product fields
  • Confusing cancellation time with login data
  • Using incorrect data types for time
3. Given this pseudocode for refund calculation:
if cancellation_time <= allowed_cancellation_time:
    refund_amount = full_price
else:
    refund_amount = 0
print(refund_amount)

What will be printed if cancellation_time is after allowed_cancellation_time?
medium
A. Error
B. full_price
C. 0
D. null

Solution

  1. Step 1: Analyze the condition

    If cancellation_time is after allowed_cancellation_time, the else branch runs.

  2. Step 2: Determine refund amount

    In else, refund_amount is set to 0, so 0 will be printed.

  3. Final Answer:

    0 -> Option C

  4. Quick Check:

    Late cancellation = zero refund [OK]
Hint: Late cancellations get zero refund [OK]
Common Mistakes:
  • Assuming refund is full regardless of time
  • Expecting an error due to condition
  • Confusing variable names
4. Identify the bug in this refund policy code snippet:
def calculate_refund(cancellation_time, allowed_time, price):
    if cancellation_time > allowed_time:
        refund = price
    else:
        refund = 0
    return refund
medium
A. Price variable is not used
B. Refund is given after allowed time instead of before
C. Function does not return any value
D. Refund is always zero

Solution

  1. Step 1: Understand refund logic

    Refund should be given if cancellation_time is before or equal to allowed_time.

  2. Step 2: Check condition logic

    Current code gives refund if cancellation_time is after allowed_time, which is incorrect.

  3. Final Answer:

    Refund is given after allowed time instead of before -> Option B

  4. Quick Check:

    Refund condition reversed = bug [OK]
Hint: Refund condition must check cancellation before allowed time [OK]
Common Mistakes:
  • Reversing the refund condition
  • Ignoring return statement
  • Misusing price variable
5. You are designing a cancellation and refund system for an online booking platform. Which approach best balances user trust and system scalability?
hard
A. Allow partial refund based on how close cancellation is to booking time
B. Allow full refund anytime, no restrictions
C. Allow full refund only if cancellation is made 24 hours before booking time, else no refund
D. Never allow refunds to avoid complexity

Solution

  1. Step 1: Consider user trust

    Partial refunds based on cancellation timing show fairness and flexibility, building trust.

  2. Step 2: Consider system scalability

    Partial refund rules can be implemented with clear logic and scale well without manual intervention.

  3. Step 3: Evaluate other options

    Full refund anytime is costly; no refunds reduce trust; strict cutoff is less flexible.

  4. Final Answer:

    Allow partial refund based on how close cancellation is to booking time -> Option A

  5. Quick Check:

    Partial refund balances trust and scalability [OK]
Hint: Partial refunds balance fairness and system load best [OK]
Common Mistakes:
  • Choosing no refund which harms user trust
  • Allowing full refund anytime which is costly
  • Using strict cutoff without flexibility