Cancellation and refund policy in LLD - System Design Exercise

Design: Cancellation and Refund Policy System

In scope: cancellation request handling, refund calculation, refund processing, notifications, policy management. Out of scope: payment gateway implementation, user authentication system.

Functional Requirements

FR1: Allow users to request cancellation of their orders or bookings.

FR2: Support different cancellation policies based on product or service type.

FR3: Calculate refund amount based on policy rules and time of cancellation.

FR4: Process refunds through payment gateways securely.

FR5: Notify users about cancellation status and refund details.

FR6: Maintain audit logs of cancellation and refund transactions.

FR7: Allow administrators to update cancellation and refund policies.

Non-Functional Requirements

NFR1: Handle up to 10,000 cancellation requests per hour.

NFR2: Refund processing latency should be under 5 seconds for 95% of requests.

NFR3: System availability target is 99.9% uptime.

NFR4: Ensure data consistency between cancellation requests and payment refunds.

NFR5: Secure handling of sensitive payment and user data.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway for receiving cancellation requests

Cancellation Service to validate and process requests

Policy Engine to apply rules for refund calculation

Payment Service to initiate refunds

Notification Service for user communication

Admin Portal for policy updates

Database for storing policies, requests, and logs

Design Patterns

Rule Engine pattern for flexible policy management

Event-driven architecture for asynchronous refund processing

Circuit Breaker pattern for payment gateway reliability

Audit Logging for compliance and traceability

Reference Architecture

  +-------------+       +----------------+       +----------------+
  |  User/API   | --->  | Cancellation   | --->  | Policy Engine   |
  |  Gateway    |       | Service        |       | (Rules & Logic) |
  +-------------+       +----------------+       +----------------+
         |                      |                        |
         |                      v                        v
         |               +----------------+       +----------------+
         |               | Payment Service |       | Notification   |
         |               | (Refunds)      |       | Service        |
         |               +----------------+       +----------------+
         |                      |                        |
         |                      v                        v
         |               +----------------+       +----------------+
         |               | Database       |       | Admin Portal   |
         |               | (Policies,     |       | (Policy Mgmt)  |
         |               | Requests, Logs)|       +----------------+
         |               +----------------+

Components

API Gateway

REST API

Receive cancellation requests from users or client apps.

Cancellation Service

Microservice (Node.js/Python)

Validate requests, check eligibility, and coordinate refund processing.

Policy Engine

Rule Engine (Drools or custom)

Apply cancellation and refund rules based on product type and timing.

Payment Service

Integration with Payment Gateway APIs

Initiate refund transactions securely and handle payment responses.

Notification Service

Email/SMS/Push Notification system

Inform users about cancellation status and refund details.

Admin Portal

Web Application (React/Angular)

Allow administrators to create and update cancellation policies.

Database

Relational DB (PostgreSQL)

Store policies, cancellation requests, refund transactions, and audit logs.

Request Flow

1. User sends cancellation request via API Gateway.

2. Cancellation Service receives and validates the request.

3. Cancellation Service queries Policy Engine for applicable rules.

4. Policy Engine returns refund amount and eligibility.

5. Cancellation Service initiates refund via Payment Service.

6. Payment Service processes refund with payment gateway.

7. Payment Service returns success or failure status.

8. Cancellation Service updates database with transaction details.

9. Notification Service sends confirmation or failure message to user.

10. Admin Portal allows policy updates which are saved in the database.

Database Schema

Entities: - User (user_id, name, contact_info) - Product (product_id, type, description) - CancellationPolicy (policy_id, product_type, rules_json, effective_date) - CancellationRequest (request_id, user_id, product_id, request_date, status, refund_amount) - RefundTransaction (transaction_id, request_id, payment_gateway_id, amount, status, timestamp) - AuditLog (log_id, entity_type, entity_id, action, timestamp, details) Relationships: - User 1:N CancellationRequest - Product 1:N CancellationRequest - CancellationPolicy linked by product_type - CancellationRequest 1:1 RefundTransaction - AuditLog tracks changes on all entities

Scaling Discussion

Bottlenecks

High volume of concurrent cancellation requests causing service overload.

Payment gateway rate limits slowing refund processing.

Database contention on policy and request tables.

Notification service delays due to high message volume.

Solutions

Implement request queueing and rate limiting at API Gateway.

Use asynchronous refund processing with retries and circuit breakers.

Partition database tables by product type or region; use read replicas.

Use scalable messaging systems (e.g., Kafka) for notifications with worker pools.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying policies, 15 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 10 minutes for questions and summary.

Explain how cancellation policies vary and need flexible rules.

Describe separation of concerns: validation, policy evaluation, payment, notification.

Highlight asynchronous processing for refunds to improve user experience.

Discuss data consistency and audit logging for compliance.

Address scaling challenges and solutions realistically.

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