# Meet-up Database Design --- **Document Version:** 1.0 **Project:** Student Bazaar **Document Type:** Meet-up Database Schema **Status:** Approved **Last Updated:** 28 June 2026 **Author:** Nemmi Tangha --- # 1. Overview The Meet-up module manages the scheduling and completion of in-person meetings between students after a price negotiation has been successfully completed. A meet-up can only be created after an offer has been accepted. The module consists of one table: 1. meetups The Meet-up module integrates directly with the Marketplace, Negotiation, Chat, and Notifications modules. --- # 2. Table: meetups ## Purpose Stores scheduled meet-ups between buyers and sellers after an offer has been accepted. Each meet-up records the agreed meeting place, scheduled time, confirmation status, and completion status. --- ## Columns | Column | Data Type | Nullable | Default | Key | Description | | ------------------- | --------------------------------------------------- | -------- | ----------------- | ------ | -------------------------------- | | id | BIGINT | No | AUTO_INCREMENT | PK | Internal primary key | | public_id | CHAR(36) | No | UUID | UNIQUE | Public identifier | | listing_id | BIGINT | No | — | FK | References listings.id | | accepted_offer_id | BIGINT | No | — | FK | References offers.id | | buyer_id | BIGINT | No | — | FK | References users.id | | seller_id | BIGINT | No | — | FK | References users.id | | scheduled_at | DATETIME | No | — | INDEX | Scheduled date and time | | meeting_place | VARCHAR(200) | No | — | — | Agreed meeting place | | notes | VARCHAR(500) | Yes | NULL | — | Optional meet-up instructions | | status | ENUM('scheduled','completed','cancelled','expired') | No | scheduled | INDEX | Current meet-up status | | buyer_confirmed | BOOLEAN | No | FALSE | — | Indicates buyer confirmation | | seller_confirmed | BOOLEAN | No | FALSE | — | Indicates seller confirmation | | buyer_confirmed_at | DATETIME | Yes | NULL | — | Time buyer confirmed completion | | seller_confirmed_at | DATETIME | Yes | NULL | — | Time seller confirmed completion | | cancellation_reason | VARCHAR(300) | Yes | NULL | — | Optional cancellation reason | | completed_at | DATETIME | Yes | NULL | INDEX | Time meet-up was completed | | created_at | DATETIME | No | CURRENT_TIMESTAMP | INDEX | Record creation timestamp | | updated_at | DATETIME | No | CURRENT_TIMESTAMP | — | Last update timestamp | --- ## Relationships * One Listing → One Meet-up * One Accepted Offer → One Meet-up * One Buyer → Many Meet-ups * One Seller → Many Meet-ups --- ## Indexes * PRIMARY KEY (`id`) * UNIQUE (`public_id`) * INDEX (`listing_id`) * INDEX (`accepted_offer_id`) * INDEX (`buyer_id`) * INDEX (`seller_id`) * INDEX (`scheduled_at`) * INDEX (`status`) * INDEX (`completed_at`) * INDEX (`created_at`) --- ## Business Rules * A meet-up may only be created after an offer has been accepted. * Every meet-up belongs to exactly one listing. * Every meet-up references exactly one accepted offer. * Only the buyer and seller may access the meet-up. * Both participants must confirm completion. * A listing becomes **Sold** only after both participants have confirmed the meet-up. * Cancelled meet-ups do not automatically cancel the accepted offer. * Expired meet-ups may be rescheduled if both participants agree. --- # 3. Meet-up Workflow The meet-up process follows this sequence: ```text Offer Accepted │ ▼ Meet-up Scheduled │ ▼ Buyer & Seller Meet │ ▼ Buyer Confirms │ ▼ Seller Confirms │ ▼ Meet-up Completed │ ▼ Listing Status → Sold ``` If either participant cancels or the scheduled time passes without completion, the meet-up may become **Cancelled** or **Expired**. --- # 4. Meet-up Constraints The Meet-up module follows these constraints: * One accepted offer can create only one meet-up. * A meet-up cannot exist without an accepted offer. * Both participants must belong to the associated listing. * Meet-up confirmations cannot be revoked after completion. * Completed meet-ups cannot be modified. --- # 5. Meet-up Security Rules The Meet-up module enforces the following security measures: * Authentication is required for all meet-up actions. * Ownership validation is required before viewing or updating a meet-up. * SQLAlchemy ORM must be used for all database operations. * All inputs must be validated before storage. * Unauthorized users cannot access meet-up details. * Security events should be logged for scheduling, cancellation, and completion. --- # 6. Module Integration ## Marketplace * Updates the listing status to **Sold** after successful completion. * Displays scheduled meet-up information to participants. --- ## Negotiation * A meet-up can only be created after an offer has been accepted. * References the accepted offer. --- ## Chat * Participants continue communicating through the existing conversation before the meet-up. * Chat remains available until the conversation is closed. --- ## Notifications Notifications are generated when: * A meet-up is scheduled. * A meet-up is updated. * A participant confirms completion. * A meet-up is cancelled. * A meet-up expires. * A meet-up is completed. --- # 7. Summary The Meet-up module provides a structured process for scheduling and completing in-person exchanges between students. The design supports: * Secure scheduling * Completion confirmation * Marketplace integration * Negotiation integration * Chat integration * Notification generation * Future scalability The Meet-up module follows the approved Student Bazaar database standards and provides the foundation for all post-negotiation interactions.