Collections Overview

The database consists of the following main collections:

artist-clients - Manages relationships between artists and their clients
availability - Stores availability schedules and time slots
bookings - Contains booking/appointment information
conversations - Stores messaging and communication data
customerPaymentInfo - Manages customer payment-related information
user-notifications - Handles user notification settings and data
user-onboarding - Stores user onboarding progress and related data
users - Contains core user profile information and details

Database Diagram

Database Schema Diagram

The diagram above shows the main collections in our Firebase database and how they relate to each other. Each connection line represents a relationship between collections, typically through document references.

Collection Schemas

artist-clients

The artist-clients collection uses a nested structure to manage the relationship between artists and their clients:

// Top level document is the artist's user ID
artist-clients/{artistId}/

// Contains a subcollection of clients
artist-clients/{artistId}/clients/{clientId}/ {
  bookingIds: string[],        // Array of booking IDs associated with this client
  clientId: string,            // Reference to the client's user ID
  firstBookingDate: number,    // Timestamp of first booking
  notes: string,              // Artist's notes about the client
  totalSpent: number          // Total amount spent by client with this artist
}

Key Details:

The collection uses a nested structure for efficient querying of artist-client relationships
Each artist’s document contains a subcollection of their clients
Client documents track booking history, spending, and artist notes
The bookingIds array enables quick access to all bookings between the artist and client
firstBookingDate is stored as a timestamp for chronological ordering

bookings

The bookings collection stores all booking information between artists and clients. Each booking document goes through various states in its lifecycle:

bookings/{bookingId} {
  // Base fields (present in all booking states)
  id: string,                  // Unique booking identifier
  createdAt: number,           // Timestamp of booking creation
  lastUpdatedAt: number,       // Timestamp of last update
  status: BookingStatusEnum,   // Current status of the booking
  customerUserId: string,      // Reference to the customer's user ID
  artistUserId: string,        // Reference to the artist's user ID
  conversationId: string,      // Reference to associated conversation
  referenceNumber: string,     // Human-readable booking reference

  // Tattoo Information
  bookingTattooInfo: {
    requestType: "Flash" | "Custom",
    description: string,
    isCoverUp: boolean,
    color: string,
    length: number,
    width: number,
    tattooPlacement: string[],
    tattooStyle: string[],
    images: string[],          // URLs to reference images
    links?: string[],          // Optional additional reference links
    selectedDates: number[],   // Preferred dates
    desiredTimeOfDay: "Morning" | "Afternoon" | "Either",
    medicalConditions?: string,
    isOver18: boolean
  },

  // Booking Details (optional until confirmed)
  location?: string,           // Tattoo location/studio
  dateTimestamp?: number,      // Confirmed date
  startTime?: number,          // Start time
  endTime?: number,           // End time
  totalFee?: string,          // Total cost
  depositFee?: string,        // Required deposit amount
  notes?: string,             // Additional booking notes
  reviewId?: string          // Reference to review (only for completed bookings)
}

Booking Status Lifecycle:

The booking goes through different states, tracked by the status field:

REQUESTED: Initial state when client submits booking request
AWAITING_DEPOSIT: Artist has accepted and waiting for client’s deposit
CONFIRMED: Deposit received and booking is confirmed
COMPLETED: Tattoo session completed
CANCELLED: Booking was cancelled

Key Details:

Each booking document contains all necessary information about the tattoo request
The status field determines which fields are required/optional
Images and links are stored as URLs, with actual files in Firebase Storage
Timestamps are stored as numbers for efficient querying
The booking maintains references to both the artist and client
A conversation is automatically created and linked to each booking

conversations

The conversations collection manages messaging between users, with a nested structure for messages:

conversations/{conversationId} {
  id: string,                    // Unique conversation identifier
  artistId: string,              // Reference to the artist
  clientId: string,              // Reference to the client
  lastMessageText: string,       // Preview of the most recent message
  lastMessageTimestamp: number,  // Timestamp of the most recent message
  unreadCounts: {               // Tracks unread messages for each participant
    [userId: string]: number
  },
  bookingIds: string[],          // Array of associated booking IDs
  createdAt: number,             // When the conversation was created
}

// Subcollection for messages
conversations/{conversationId}/messages/{messageId} {
  // Base message fields
  id: string,                    // Unique message identifier
  senderId: string,              // User ID of the sender
  timestamp: number,             // Message timestamp
  readBy: string[],              // Array of user IDs who have read the message

  // Message content (varies by type)
  type: MessageTypeEnum,         // TEXT | FILE | REQUEST | CONFIRMATION | CANCELLED | EDIT

  // Type-specific fields
  // For TEXT messages:
  text?: string,                 // Message content for text messages

  // For FILE messages:
  name?: string,                 // Original filename
  fileType?: string,            // MIME type of the file
  fileUrl?: string,             // Storage URL for the file

  // For REQUEST messages:
  // ... includes BookingTattooInfo fields

  // For CONFIRMATION messages:
  dateTimestamp?: number,        // Confirmed booking date
  startTime?: number,           // Start time
  endTime?: number,             // End time
  notes?: string,               // Additional notes
  price?: number,               // Confirmed price

  // New field for booking-related messages
  bookingId?: string,           // Reference to related booking if message is booking-related
}

Message Types:

The messages subcollection supports different types of messages:

TEXT: Standard text messages
FILE: File attachments (images, documents, etc.)
REQUEST: Booking requests with tattoo details
CONFIRMATION: Booking confirmation details
CANCELLED: Booking cancellation notifications
EDIT: Booking edit notifications

Currently each conversation is unique per booking. We might want to refactor this to be one conversation per artist-client pair in the future.

Key Details:

Each conversation document tracks participants and message metadata
The unreadCounts map enables efficient unread message tracking per user
lastMessageText and lastMessageTimestamp enable conversation previews
Messages are stored in a subcollection for efficient pagination
File messages store URLs pointing to Firebase Storage
Special message types (REQUEST, CONFIRMATION) integrate with the booking system
The readBy array tracks message read status for all participants

user-notifications

The user-notifications collection manages notification state and history for each user, with a nested structure for individual notifications:

user-notifications/{userId} {
  id: string,                    // User ID
  lastUpdated: number,           // Timestamp when notifications were last viewed
  newNotificationIds: string[],  // Array of unviewed notification IDs
}

// Subcollection for individual notifications
user-notifications/{userId}/notifications/{notificationId} {
  id: string,                    // Unique notification identifier
  userId: string,                // ID of user receiving notification
  createdAt: number,             // Timestamp when notification was created
  isRead: boolean,               // Whether the notification has been read
  type: NotificationTypeEnum,    // Type of notification
  data: NotificationDataMap[T]   // Type-specific notification data
}

Notification Types

The system primarily supports booking-related notifications that track the lifecycle of a booking:

Booking Status Updates: Notifications for new requests, confirmations, edits, cancellations, and declines
Payment Updates: Notifications for deposit payments (to be implemented)
System Updates: Platform-wide notifications like new feature announcements (to be implemented)

Each notification includes relevant context like booking IDs and user names for display purposes.

Key Details:

Each user has a document tracking their notification state
lastUpdated tracks when the user last viewed their notifications
newNotificationIds maintains a list of notifications that appeared since the last view
Individual notifications are stored in a subcollection for efficient pagination
The isRead flag tracks individual notification read status
Notification data is type-safe through TypeScript generics

user-onboarding

The user-onboarding collection tracks the onboarding progress for users:

user-onboarding/{userId} {
  verifyEmail: boolean,        // Whether user has verified their email
  completeProfile: boolean,    // Whether user has completed their profile
  setupCalendar: boolean,      // Whether user has set up their availability calendar
  shareBookingLink: boolean,   // Whether user has configured their booking link
  setupPayments: boolean,      // Whether user has set up payment methods
  updatedAt: Date             // Last time onboarding status was updated
}

Key Details:

Each document represents a user’s onboarding progress
Boolean flags track completion status of each onboarding step
Steps include email verification, profile setup, calendar configuration, booking link setup, and payment setup
updatedAt field helps track when users last made progress in onboarding
Used to guide users through the necessary setup steps before they can fully use the platform

users

The users collection stores core user profile information and extends Firebase Authentication user data:

users/{userId} {
  // Basic Information
  id: string,                    // Firebase Auth User ID
  email: string,                 // User's email address
  firstName: string,             // First name
  lastName: string,              // Last name
  displayName: string,           // Full display name
  phoneNumber: {                 // Optional phone number
    countryCode: string,         // e.g., "+61"
    number: string,              // e.g., "0482394387"
  } | null,
  photoURL: string,              // Profile photo URL

  // Profile Details
  bio: string,                   // User's biography/description
  createdAt: number,             // Account creation timestamp
  location?: string,             // User's location
  pronouns: "Don't Specify" | "He/Him" | "She/Her" | "They/Them" | "Other",
  otherPronouns?: string,        // Custom pronouns if "Other" selected

  // Artist-specific fields
  userType?: "artist" | "client", // User role (defined after onboarding)
  styles: string[],              // Artist's tattoo styles
  socialMedia: {
    instagram: string,           // Instagram profile URL
  },

  // Miscellaneous
  howDidYouHearAboutUs?: string  // Platform discovery information
}

Key Details:

Extends Firebase Authentication with additional user profile information
Supports both artist and client user types
Artists have additional fields for styles, social media, and payment processing
Profile photos and media are stored in Firebase Storage with URLs in the document
Some fields become required based on user type and onboarding progress
Integrates with Stripe for artist payment processing
Social media integration currently focuses on Instagram, with potential for expansion

availability

This collection is still under development

The availability collection will manage artist availability and scheduling:

// Schema to be implemented
availability/{artistId} {
  // ... schema details coming soon
}

customerPaymentInfo

This collection is still under development

The customerPaymentInfo collection will handle customer payment methods and history:

// Schema to be implemented
customerPaymentInfo/{userId} {
  // ... schema details coming soon
}

Relationships

The database is built around several key relationships that enable the booking and communication flow:

Core User Relationships

users ↔ user-onboarding: Each user has an onboarding document tracking their setup progress
users ↔ user-notifications: Each user has a notifications document with their notification history
users ↔ artist-clients: Artists have client relationships stored in nested collections

Booking Flow

bookings ↔ users: Each booking references both an artist and a client
bookings ↔ conversations: Each booking has an associated conversation for communication
bookings ↔ artist-clients: Bookings are tracked in the artist-client relationship

Communication

conversations ↔ users: Conversations track participants and their read/unread status
conversations ↔ bookings: Messages can contain booking-related actions (requests, confirmations)
user-notifications ↔ bookings: Notifications are generated for booking status changes

This interconnected structure ensures that:

Artists can manage their client relationships and booking history
Clients can track their bookings and communications with artists
All booking-related actions are properly communicated and tracked
User progress and notifications are properly managed

Data Access Patterns

[To be populated with common data access patterns]

Security Rules

[To be populated with Firebase security rules overview]

Best Practices

[To be populated with database-specific best practices]

Welcome

Product

Engineering

Mintlify Blocks

Database Structure

Collections Overview

Database Diagram

Collection Schemas

artist-clients

Key Details:

bookings

Booking Status Lifecycle:

Key Details:

conversations

Message Types:

Key Details:

user-notifications

Notification Types

Key Details:

user-onboarding

Key Details:

users

Key Details:

availability

customerPaymentInfo

Relationships

Core User Relationships

Booking Flow

Communication

Data Access Patterns

Security Rules

Best Practices

​Collections Overview

​Database Diagram

​Collection Schemas

​artist-clients

​Key Details:

​bookings

​Booking Status Lifecycle:

​Key Details:

​conversations

​Message Types:

​Key Details:

​user-notifications

​Notification Types

​Key Details:

​user-onboarding

​Key Details:

​users

​Key Details:

​availability

​customerPaymentInfo

​Relationships

​Core User Relationships

​Booking Flow

​Communication

​Data Access Patterns

​Security Rules

​Best Practices

Collections Overview

Database Diagram

Collection Schemas

artist-clients

Key Details:

bookings

Booking Status Lifecycle:

Key Details:

conversations

Message Types:

Key Details:

user-notifications

Notification Types

Key Details:

user-onboarding

Key Details:

users

Key Details:

availability

customerPaymentInfo

Relationships

Core User Relationships

Booking Flow

Communication

Data Access Patterns

Security Rules

Best Practices