Design a Database Schema for a New Feature

Act as a senior engineer designing a relational schema. Design the tables for this feature, and show me the decisions you're making so I can challenge them.

Database: {{DIALECT}}
Feature and the main things users do with it: {{FEATURE}}
Existing related tables: {{EXISTING_SCHEMA}}
Expected volumes and the most frequent queries: {{ACCESS_PATTERNS}}

Produce:
1. Entities and relationships in plain English, including cardinality (one-to-many, many-to-many).
2. CREATE TABLE statements with types, primary keys, foreign keys with ON DELETE behavior, NOT NULL and CHECK constraints, unique constraints, and defaults.
3. Indexes driven by the access patterns, with the query each one serves.
4. The decisions, each with the alternative and why you chose this: surrogate versus natural keys, soft versus hard delete, how money and time are stored (integer minor units or decimal; UTC timestamps), enums versus lookup tables, JSON columns versus normalized tables.
5. Data integrity risks the schema can't prevent on its own, and where the application must enforce them.
6. Three sample queries for the main access patterns.

Keep it as simple as the feature allows. If my access patterns are unclear, list the questions that would change the design.