Cancellation and refund policy in LLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the cancellation status in the policy class.

LLD

class CancellationPolicy:
    def __init__(self):
        self.status = '[1]'

Drag options to blanks, or click blank then click option'

Aactive

Bcancelled

Cpending

Drefunded

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing 'cancelled' as initial status which means policy is inactive.

The cancellation policy starts with an 'active' status indicating it is valid.

2fill in blank

medium

Complete the method to check if a refund is allowed based on the policy status.

LLD

def can_refund(self):
    return self.status == '[1]'

Drag options to blanks, or click blank then click option'

Aactive

Bexpired

Ccancelled

Drefunded

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'active' which means policy is still valid.

Refunds are allowed only if the policy status is 'cancelled'.

3fill in blank

hard

Fix the error in the refund calculation method to correctly compute refund amount.

LLD

def calculate_refund(self, amount):
    if self.status == 'cancelled':
        return amount [1] 0.8
    else:
        return 0

Drag options to blanks, or click blank then click option'

A*

B+

C-

D/

Attempts:

3 left

💡 Hint

Common Mistakes

Using '+' or '-' which changes the amount incorrectly.

The refund is 80% of the amount, so multiplication by 0.8 is correct.

4fill in blank

hard

Fill both blanks to complete the policy update method that sets status and logs the change.

LLD

def update_policy(self, new_status):
    self.status = [1]
    print('Policy status changed to', [2])

Drag options to blanks, or click blank then click option'

Anew_status

B'new_status'

Cself.status

D'self.status'

Attempts:

3 left

💡 Hint

Common Mistakes

Using string literals instead of variables.

The status is updated to the variable new_status, and the current status is printed.

5fill in blank

hard

Fill all three blanks to complete the refund eligibility check with time and status conditions.

LLD

def is_refund_eligible(self, days_since_purchase):
    return self.status == [1] and days_since_purchase [2] [3]

Drag options to blanks, or click blank then click option'

A'cancelled'

B<=

C30

D>

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong comparison operators or status strings.

Refund is eligible if status is 'cancelled' and purchase was within 30 days.

Practice

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