Skip to content

PRD-015: Booking Cancellation Feature

Status: Approved
Author: Product Team
Date: 2024-01-15
Epic: Booking Management

1. Overview

Problem Statement

Users currently cannot cancel their bookings through the application. They must contact customer support, leading to increased support costs and poor user experience.

Objective

Enable users to self-serve booking cancellations directly through the application, improving user experience and reducing support burden.

Success Metrics

  • 80% of cancellations handled through self-service (no support contact)
  • Cancellation flow completion rate > 90%
  • Average cancellation time < 2 minutes
  • Support ticket volume reduced by 50% for cancellation requests

2. User Stories

US-015-1: User Cancels Confirmed Booking

As a user with a confirmed booking
I want to cancel my booking
So that I can free up the reservation when my plans change

Acceptance Criteria: - User can view their confirmed bookings - User can click "Cancel Booking" on a confirmed booking - System prompts user to provide cancellation reason - System displays cancellation confirmation - User receives email notification of cancellation - Cancelled bookings appear in "Cancelled" tab

US-015-2: User Views Cancellation History

As a user
I want to view my cancelled bookings
So that I can track my booking history

Acceptance Criteria: - Cancelled bookings show cancellation date - Cancelled bookings show cancellation reason - Historical data retained for at least 12 months

US-015-3: Prevent Invalid Cancellations

As a system
I want to prevent cancellation of invalid bookings
So that data integrity is maintained

Acceptance Criteria: - Cannot cancel already-cancelled bookings - Cannot cancel completed bookings - Cannot cancel another user's bookings - Clear error messages for invalid operations

3. Non-Functional Requirements (NFRs)

Performance

  • NFR-015-1: Cancellation API response time < 500ms (p95)
  • NFR-015-2: Notification delivery within 30 seconds of cancellation

Reliability

  • NFR-015-3: 99.9% uptime for cancellation endpoint
  • NFR-015-4: Zero data loss for cancellation events
  • NFR-015-5: Guaranteed notification delivery (at-least-once)

Security

  • NFR-015-6: Users can only cancel their own bookings
  • NFR-015-7: All cancellation actions logged for audit
  • NFR-015-8: Authorization checks on every cancellation request

Scalability

  • NFR-015-9: Support 1000 concurrent cancellation requests
  • NFR-015-10: Handle 50,000 cancellations per day

4. Business Rules

BR-015-1: Cancellation Eligibility

Only bookings with status = confirmed can be cancelled.

BR-015-2: State Transitions

  • confirmed → cancelled (allowed)
  • cancelled → any state (not allowed, terminal state)
  • completed → any state (not allowed, terminal state)

BR-015-3: Cancellation Reason

Users must provide a cancellation reason from predefined options: - Change of plans - Double booking - Found alternative - No longer needed - Other (with free text)

BR-015-4: Notification Requirements

Upon successful cancellation: 1. Send email to user with cancellation details 2. Send notification to property/resource owner 3. Trigger refund processing (if applicable)

5. Out of Scope

The following are explicitly NOT included in this release: - Partial cancellations (cancelling only some items in a booking) - Cancellation fees or penalties - Refund processing logic (handled by separate payment service) - Cancellation deadlines or time windows - Waitlist management for freed-up slots

6. Technical Constraints

TC-015-1: Service Architecture

Must integrate with existing booking-service microservice.

TC-015-2: Database

Use existing PostgreSQL database for booking state.

TC-015-3: Event Publishing

Use Kafka for publishing cancellation events to downstream services.

TC-015-4: API Standards

Follow existing REST API conventions (versioned, JSON responses).

7. Dependencies

Internal Dependencies

  • Booking Service: Core booking management service
  • Notification Service: Email and push notification delivery
  • User Service: User authentication and authorization

External Dependencies

  • Property Management System: Sync cancelled bookings with external PMS
  • Email Service Provider: SendGrid for email delivery

8. Risks

R-015-1: Race Conditions

Risk: Concurrent cancellation requests for same booking
Mitigation: Database-level constraints and optimistic locking

R-015-2: Event Delivery Failures

Risk: Notification service unavailable during cancellation
Mitigation: Use transactional outbox pattern for guaranteed delivery

R-015-3: High Cancellation Volume

Risk: Unexpected spike in cancellations (e.g., weather event)
Mitigation: Auto-scaling configuration and rate limiting

9. Open Questions

Q1: Should we allow cancellation within X hours of booking start time?
Answer: Not in this phase. Future enhancement.

Q2: Do we need a cancellation confirmation step (double-confirm)?
Answer: Yes, show confirmation modal before executing cancellation.

Q3: Should we log IP address for audit purposes?
Answer: Yes, for security and fraud detection.

10. Timeline

  • Design Phase: Week of Jan 22
  • Implementation: Jan 29 - Feb 9
  • Testing: Feb 12 - Feb 16
  • Deployment: Feb 19 (soft launch to 10% users)
  • Full Release: Feb 26

Appendix A: UI Mockups

(Link to Figma designs)

Appendix B: API Contract Draft

POST /v1/bookings/{booking_id}/cancel
{
  "reason": "change_of_plans",
  "notes": "Optional free text"
}

Approval Signatures: - Product Manager: ✓ - Engineering Lead: ✓ - UX Design: ✓ - Legal/Compliance: ✓