1. Overview

This document provides a detailed design for the ticket booking function. This functionality allows users to search for, book, and pay for event tickets, as well as receive confirmation of their bookings.

2. System Architecture

The system consists of the following main components:

  • Frontend: Web application
  • Backend API: RESTful API
  • Database: Relational Database Management System (RDBMS)

3. API Specifications

3.1 User Management

  • Endpoint: /users

  • Method: POST

  • Functionality: Create a new user

  • Request Body:

    
{
  "username": "johndoe",
  "email": "[email protected]",
  "password": "password123"
}

  • Response:

    • Success (201 Created):
    
{
  "user_id": 1,
  "username": "johndoe",
  "email": "[email protected]",
  "created_at": "2023-05-01T12:00:00Z"
}

3.2 Ticket Search

  • Endpoint: /tickets

  • Method: GET

  • Functionality: Get available tickets

  • Response:

    • Success (200 OK):
    
[
  {
    "ticket_id": 1,
    "event_name": "Connan movie 27",
    "event_date": "2024-07-05 20:00:00",
    "price": 120,000,
    "available": 100
  }
]

3.3 Ticket Booking

  • Endpoint: /bookings

  • Method: POST

  • Functionality: Book a ticket

  • Request Body:

    
{
  "user_id": 1,
  "ticket_id": 1
}

  • Response:

    • Success (201 Created):
    
{
  "booking_id": 1,
  "user_id": 1,
  "ticket_id": 1,
  "booking_date": "2024-05-26 10:25:00",
  "status": "confirmed"
}

3.4 Payment Processing

  • Endpoint: /payments

  • Method: POST

  • Functionality: Process a payment

  • Request Body:

    
{
  "booking_id": 1,
  "amount": 120,000
}

  • Response:

    • Success (201 Created):
    jsonCopy code
{
  "payment_id": 1,
  "booking_id": 1,
  "amount": 99.99,
  "payment_date": "2024-05-26 10:30:00",
  "status": "successful"
}

4. Database Design

4.1 Table Definitions

Users Table

Column Name Data Type Constraints
user_id INT PRIMARY KEY, AUTO_INCREMENT
username VARCHAR(50) NOT NULL, UNIQUE
email VARCHAR(100) NOT NULL, UNIQUE
password VARCHAR(255) NOT NULL
created_at DATETIME NOT NULL, DEFAULT CURRENT_TIMESTAMP

Tickets Table

Column Name Data Type Constraints
ticket_id INT PRIMARY KEY, AUTO_INCREMENT
event_name VARCHAR(100) NOT NULL
event_date DATETIME NOT NULL
price DECIMAL(10, 2) NOT NULL
available INT NOT NULL

Bookings Table

Column Name Data Type Constraints
booking_id INT PRIMARY KEY, AUTO_INCREMENT
user_id INT NOT NULL, FOREIGN KEY (REFERENCES Users(user_id))
ticket_id INT NOT NULL, FOREIGN KEY (REFERENCES Tickets(ticket_id))
booking_date DATETIME NOT NULL, DEFAULT CURRENT_TIMESTAMP
status VARCHAR(50) NOT NULL

Payments Table

Column Name Data Type Constraints
payment_id INT PRIMARY KEY, AUTO_INCREMENT
booking_id INT NOT NULL, FOREIGN KEY (REFERENCES Bookings(booking_id))
amount DECIMAL(10, 2) NOT NULL
payment_date DATETIME NOT NULL, DEFAULT CURRENT_TIMESTAMP
status VARCHAR(50) NOT NULL

5. Flow

5.1 Ticket Search Flow

  1. User sends a "Search Tickets" request from the frontend.
  2. Backend receives the request and fetches available ticket information from the Database.
  3. Backend returns the ticket information to the User.

5.2 Ticket Booking Flow

  1. User sends a "Book Ticket" request from the frontend.
  2. Backend receives the request and checks the availability of the ticket in the Database.
  3. Backend saves the booking information in the Database.
  4. Backend returns the booking confirmation to the User.

5.3 Payment Flow

  1. User sends a "Process Payment" request from the frontend.
  2. Backend receives the request and sends a payment request to the Payment Gateway.
  3. Payment Gateway processes the payment and returns the result to the Backend.
  4. Backend saves the payment result in the Database.
  5. Backend returns the payment confirmation to the User.

6. Sequence Diagrams

6.1 Ticket Search Sequence

 

6.2 Ticket Booking Sequence

6.3 Payment Sequence

7. Data Validation

7.1 User Creation

  • username: Must be unique, non-empty string, max length 50.
  • email: Must be unique, valid email format, max length 100.
  • password: Must be non-empty, hashed before storage.

7.2 Ticket Booking

  • user_id: Must exist in Users table.
  • ticket_id: Must exist in Tickets table and be available.
  • status: Should be "confirmed" initially.

7.3 Payment Processing

  • booking_id: Must exist in Bookings table.
  • amount: Must match the ticket price for the booking.

8. Security Considerations

  • Use HTTPS for secure communication.
  • Implement authentication (e.g., JWT) for API endpoints.
  • Validate and sanitize all user inputs to prevent SQL injection and XSS attacks.
  • Hash and salt passwords before storing them in the database.

9. Error Handling

  • Return appropriate HTTP status codes (e.g., 400 for bad requests, 401 for unauthorized, 404 for not found, 500 for server errors).
  • Provide meaningful error messages in responses.
  • Log errors for debugging and monitoring purposes.

This detailed design document provides a comprehensive guide to implementing the ticket booking functionality, covering API specifications, database design, process flows, sequence diagrams, data validation, security considerations, and error handling.