SHoRE Fest 2026

Use cases

1. High-Level Use Case Overview

Before the specific steps, let's visualize the actors and their boundaries.

Primary Actors:

1. Attendee: The consumer (Student/Guest).
2. Volunteer (Scanner): The operational edge node.
3. Admin (Superuser): The configuration manager (IAM/Finances).
4. Domain Head (Hospitality/Events): The operational manager.
5. G-Events Portal: The external payment trigger.

2. Workflow A: The "Registration to Ticket" Journey

Goal: Convert a stranger into a verified attendee with a secure, offline-capable QR code.

The Flow:

1. Onboarding:
   • User logs in (via University Email or Guest Email).
   • System creates a basic Profile (Role: Attendee).
2. Purchase (External Dependency):
   • User selects "All Access Pass" or "Accommodation."
   • User is redirected to G-Events Portal to pay.
   • System State: Payment: Pending.
3. The Handshake (Webhook):
   • G-Events processes payment → Fires Webhook to SHoRE Backend.
   • SHoRE Backend validates payload → Updates DB to Payment: Paid.
   • Crucial Step: Backend generates the "Seed Key" for the user's cryptographic QR and sends it to the User App.
4. Ticket Generation:
   • User opens SHoRE App.
   • App detects "Paid" status + "Seed Key."
   • App starts generating Dynamic QRs (changing every 30s) locally.

Validation Question: Does the G-Events portal support sending us a unique transaction ID that we can link back to the specific student ID? (We need a common key to link the webhook).

3. Workflow B: The "Gate Access" Loop (Online Scanner, Offline User)

Goal: Process 3,000 students quickly without internet on user phones, preventing fraud.

The Flow:

1. The Approach: Attendee walks to the gate. Opens app. No Internet? No problem. App generates QR: [UserID + Timestamp + Signature].
2. The Scan: Volunteer scans QR with the Scanner App.
3. Device Validation (The "Bouncer"):
   • Scanner checks Signature (Integrity).
   • Scanner checks Timestamp (Freshness).
   • Result: If Invalid → Red Screen immediately.
4. Server Validation (The "Manager"):
   • If Valid: Scanner sends UserID to Backend via CATS Network.
   • Backend runs Atomic SQL: UPDATE checks SET in=TRUE WHERE in=FALSE.
5. The Decision:
   • Backend returns Success → Scanner flashes GREEN + Photo of Student.
   • Backend returns Fail (Already Entered) → Scanner flashes RED + "DUPLICATE ENTRY".

4. Workflow C: The "Crisis Management" Journey (IAM/RBAC)

Goal: Handling last-minute permission changes without code deployment.

The Flow:

1. The Trigger: A "Pro-Show" volunteer falls sick. A "Hospitality" volunteer needs to take their place at the entrance immediately.
2. The Intervention:
   • Admin opens SHoRE Admin Panel.
   • Finds User: "Volunteer A".
   • Current Role: Hospitality Volunteer.
3. The Adjustment (Option A - Quick Fix):
   • Admin adds a direct permission: events.proshow.scan.
   • System Action: Updates User Permissions in DB → Invalidates User Cache.
4. The Adjustment (Option B - Role Change):
   • Admin changes Role to Event Volunteer.
5. The Result:
   • "Volunteer A" refreshes their app.
   • The "Scan Ticket" button appears on their dashboard.
   • They start scanning. Time elapsed: 30 seconds.

5. Workflow D: The "Accommodation" Cycle

Goal: Managing physical check-ins for rooms.

The Flow:

The Hospitality Dashboard (Command Center)

• Actors: Hospitality Head/Lead.
• The View:
  • Head opens "Accommodation Dashboard".
  • Stats Widget: Shows "Accommodation provided: 240/500", "Rooms Filled: 120/500", "Available in Block A: 45".
  • Grid View: Lists all registered students.
• Filtering & Sorting:
  • Filters list by: Name, Phone, City, Email, Year, Male/Female, SHORE Internal-Team/Attendee.
  • Can also filter by inventory: Floor, Room.
• Venue Management:
  • Head/Lead views "Venue Inventory".
  • Head can add new venues, update existing venues, and delete venues.
1. Assignment:
   • Hospitality Head views "Paid Accommodation List" (Filter: Unassigned).
   • Head selects Student → Assigns Block A, Floor 2, Room 304. (Dropdown only shows available rooms)
2. The Override (VIP/Guest):
   • Head selects a Guest/Speaker/Attendee/SHORE Internal-Team who has NOT paid.
   • Clicks "Grant Accommodation".
   • Consider allowing them to pay if attendee.
   • System logs: Action: Manual_Override, By: Hospitality_Head.
   • User status updates to "Eligible" without payment. Room is assigned.
3. User Visibility:
   • Student opens app → "My Stay" section shows "Room 304".
4. Physical Check-in:
   • Student arrives at Hostel.
   • Hospitality Volunteer scans Student QR.
   • App shows: "Eligible for Room 304".
   • Volunteer hands over key → Taps "Check-In" on their app.
   • System updates status: Occupancy: Filled.
5. Physical Check-out:
   • Student returns key. Volunteer scans QR.
   • Volunteer taps "Check-Out".
   • System updates: Occupancy: Vacant (Room becomes available in Dropdown again).

6. Edge Case Validation (The "What Ifs")

Let's test these workflows against reality.

• Scenario 1: The G-Events Webhook fails (server busy).
  • Fix: We need a "Reconcile" button in the Admin Panel that allows us to upload a CSV from G-Events and manually mark users as "Paid."
• Scenario 2: Scanner loses CATS Network connectivity.
  • Fix: Scanner switches to "Offline Mode." Validates Crypto Signature only. Queues the "Check-in" data. Syncs when network returns. (Risk: Replay attack possible, but low probability in short window).
• Scenario 3: User phone battery dies.
  • Fix: "Manual Entry" mode. Volunteer types Student ID/Email. System pulls up Photo. Volunteer verifies face → Checks in manually.

6. Workflow E: Event Creation (The "Draft" Lifecycle)

Goal: Allow Admins to set up events without exposing them to the public immediately.

• Actors: Admin / Event Head.
• IAM Permission: event.create.
• The Flow:
  1. Drafting:
     • Admin enters details: Title, Description, Venue, Capacity, Time.
     • Crucial Step: Admin selects "Access Rule" (e.g., "Open to All" vs. "Pro-Pass Only").
     • System saves as Status: Draft. (Not visible in the App).
  2. Review (Optional):
     • Admin reviews the draft.
  3. Publishing:
     • Admin clicks "Publish."
     • System updates status to Status: Live.
     • Event becomes visible on the Website/App API.

7. Workflow F: Event Updation & Notification

Goal: Handle changes (Venue/Time) and ensure attendees are informed.

• Actors: Admin / Event Head.
• IAM Permission: event.update.
• The Flow:
  1. The Change:
     • Head changes Venue from "Auditorium" to "Open Air Theater."
  2. The Audit:
     • System logs: User: Event_Head changed Venue ID 101.
  3. The Trigger:
     • Admin checks a box: "Notify Registered Attendees?"
  4. The Broadcast:
     • If checked, System triggers a Push Notification/Email job via a background worker (Queue) to all users registered for that specific event.
     • "Alert: Venue for 'Battle of Bands' changed to OAT."

8. Workflow G: Food & Beverage (The "Digital Coupon" Model)

Goal: Manage meal distribution efficiently and prevent double-claiming.

• Actors: Attendee, F&B Volunteer.
• Prerequisite: User purchased "Hospitality Pack" (via G-Events).
• The Flow:
  1. Entitlement:
     • User profile has a ledger: { "Day1_Lunch": 1, "Day1_Dinner": 1 }.
  2. The Exchange:
     • User arrives at the Food Counter.
     • Volunteer selects "Day 1 Lunch" mode on Scanner.
  3. The Validation (Strictly Online/CATS Network):
     • Volunteer scans User QR.
     • Atomic SQL Check:

       UPDATE user_entitlements
       SET claimed = TRUE, claimed_at = NOW()
       WHERE user_id = '123' AND item = 'Day1_Lunch' AND claimed = FALSE;
       

  4. The Feedback:
     • Success (Rows=1): Green Screen. Volunteer hands over the plate.
     • Fail (Rows=0): Red Screen ("Already Ate").

The "Override" (Free Meal)

• Scenario: A Guest Lecturer/Sponsor/SHORE Internal team/Attendee needs lunch but has no ticket.
• Action: Hospitality Lead switches Scanner to "Manager Mode".
• The Flow:
  • Lead scans Guest QR.
  • App detects "No Entitlement".
  • Lead clicks "Issue Complimentary Meal".
  • System logs: Meal: Issued, Reason: Manager_Override.
  • Green Screen appears.

Stats & Inventory

• Dashboard: F&B Head views "Live Consumption Stats".
• Data Points: "Day 1 Lunch: 1,240 Served".
• Benefit: Helps kitchen team manage replenishment.

9. Workflow H: Competition Participation

Goal: Handling individual and team registrations.

• Actors: Attendee.
• The Flow:
  1. Discovery: User views "Hackathon" event page.
  2. Eligibility Check:
     • User clicks "Register."
     • System checks: Does User have the required Pass (e.g., Pro Pass)?
  3. Team Logic (If applicable):
     • Scenario A (Individual): System adds user to event_participants table.
     • Scenario B (Team Leader): User creates a Team Name → Generates a "Team Code."
     • Scenario C (Team Member): User enters "Team Code" to join.
  4. Confirmation:
     • User receives a "Registered" badge on the event card.

10. Workflow I: View Check-ins (The "Command Center")

Goal: Real-time situational awareness for crowd control.

• Actors: Admin, Security Head.
• IAM Permission: analytics.view.
• The Flow:
  1. Dashboard Load:
     • Admin opens "Live Stats."
  2. Data Aggregation (Cached):
     • Backend queries the registrations and event_logs tables.
     • Optimization: Use a Redis counter that increments on every scan to avoid heavy SQL COUNT(*) queries every second.
  3. Visualization:
     • Heatmap: Shows which Gate/Venue has high traffic.
     • Demographics: "1,200 GITAM Students" vs "300 Non-GITAM."
     • Time Series: "Entries per minute" (Detects rush hours).
  4. Drill Down:
     • Click on "Pro-Show" → See list of currently checked-in users.

11. Workflow J: Marketing Campaigns (Dynamic Content)

Goal: Creating hype without code deployments (using the Feature Flag system).

• Actors: Marketing Head, Admin.
• IAM Permission: marketing.config.
• The Flow:
  1. Configuration:
     • Marketing team designs a "Flash Sale Banner."
     • Admin uploads image to storage.
  2. Activation:
     • Admin goes to System Config in Admin Panel.
     • Sets promo_banner_active = TRUE.
     • Sets promo_image_url = .../banner.jpg.
     • Sets promo_link = .../register.
  3. User Experience:
     • User refreshes the App/Website.
     • The App checks the config API.
     • The Banner appears dynamically on the Home Screen.

12. Workflow K: Competition Lifecycle & Judging (Granular)

Goal: Manage the flow of participants through rounds and track real-time occupancy of the venue.

• Actors: Event Volunteer, Judge, Participant.
• The Flow:
  1. Venue Entry (Check-In):
     • Volunteer scans Participant QR.
     • System updates: status: checked_in, location: room_101.
     • Dashboard Update: Event Head sees "50/60 Participants present."
  2. The Judging Round:
     • Judge logs in (Role: Judge).
     • Selects "Round 1".
     • Participants are listed (filtered by checked_in).
     • Judge enters score/notes → Submit.
  3. Result Notification:
     • Event Head clicks "Publish Results."
     • System calculates top scorers.
     • Notification: Push notification sent to Winners: "You qualified for Round 2!"
     • Status Update: Losers marked status: eliminated.
  4. Venue Exit (Check-Out):
     • Volunteer scans QR on exit.
     • System updates: location: null. (Crucial for knowing if a team is missing before their turn).

13. Workflow L: Profile Management

Goal: Self-service data management.

• Actors: User.
• The Flow:
  1. View: User sees "My Profile" (Name, ID, Photo).
  2. Update:
     • User edits phone number or Instagram handle.
     • Constraint: Critical fields (Name, University ID, Email) are Locked after initial verification to prevent identity swapping.
     • To change locked fields, they must raise a Ticket (Workflow M).
  3. History: User views "My Registrations" (List of Paid Events).

14. Workflow M: Support System (Ticketing)

Goal: Centralized communication for issues.

• Actors: User, Admin.
• The Flow:
  1. Creation:
     • User clicks "Help" → "Raise Issue."
     • Selects Category: (Payment, Accommodation, App Bug).
     • Writes description → Submit.
  2. Triage:
     • Admin views "Open Tickets."
     • Assigns to specific Lead (e.g., Finance Lead for payments).
  3. Resolution:
     • Lead replies: "Fixed, please retry."
     • Lead changes status: Resolved.
  4. Feedback: User gets notified and can reopen if not satisfied.

15. Workflow N: Non-GITAM Verification (The "Gatekeeper")

Goal: Security vetting for outsiders.

• Actors: Non-GITAM User, Admin (Security Team).
• The Flow:
  1. Upload: User registers → Uploads Gov ID / College ID photo.
  2. Pending State: System locks QR generation. Status: Verification Pending.
  3. The Review:
     • Admin views "Pending Queue."
     • Admin compares Name on form vs. Name on ID Card.
  4. Action:
     • Approve: Unlocks Payment/QR. Sends "Welcome" email.
     • Reject: Sends email "ID unclear, please re-upload."

16. Workflow O: IAM & Team Management

Goal: Onboarding the team.

• Actors: Super Admin.
• The Flow:
  1. Invite: Admin enters email new_lead@shore.in. Selects Role: Events Lead.
  2. Onboarding:
     • System sends Email Invite.
     • User clicks link → Sets Password.
  3. Access: User logs in. The permissions table automatically loads the "Events Lead" capabilities.
  4. Offboarding: Admin clicks "Deactivate." User session is killed immediately.

17. Workflow P: Mystery QR (Gamification)

Goal: A digital scavenger hunt to drive engagement.

• Actors: Attendee.
• The Setup:
  • Marketing team prints 10 unique static QRs and hides them around campus.
  • Database table mystery_qrs contains the hashes of these codes.
• The Flow:
  1. Scan: User finds a hidden QR → Scans with SHoRE App.
  2. Validation:
     • App sends Hash to Server.
     • Server checks: "Has this user scanned this specific QR before?"
  3. Reward:
     • If No: User_Points += 50. Show "You found Clue #1!"
     • If Yes: Show "Already Collected."
  4. Leaderboard: App displays "Top Hunters."

18. Workflow Q: Instagram Integration

Goal: Social proof on the dashboard.

• Actors: System (Cron Job), Marketing Head.
• The Flow:
  1. Connection: Admin authenticates with "Instagram Graph API."
  2. Sync (Background Job):
     • Every 1 hour, server fetches: Follower Count, Latest Post Likes, Hashtag Mentions.
  3. Display:
     • Admin Dashboard shows a "Social Reach" graph.
     • Public Website shows: "Join our 10K+ Community!"

19. Workflow R: Artist Lineup Management

Goal: CMS for the website.

• Actors: Event Head.
• The Flow:
  1. Edit: Head opens "Artist Manager."
  2. Update:
     • Uploads Photo of "Band X".
     • Adds Bio, Instagram Link, Spotify Link.
  3. Publish:
     • API endpoint /api/artists updates.
     • Website/App reflects the new lineup immediately.

20. Workflow S: FAQ Management

Goal: Reducing support tickets.

• Actors: Content Team.
• The Flow:
  1. Draft: Admin adds Question & Answer. Category: "Transport."
  2. Publish: Instant update to the /api/faq endpoint.
  3. View: Users search FAQs in the app.

21. Workflow T: Countdown Timer

Goal: Hype generation.

• Actors: Admin.
• The Flow:
  1. Config: Admin sets event_start_timestamp in System Config.
  2. Sync: App fetches this timestamp on launch.
  3. Display: App calculates Time Now - Start Time locally and updates the ticker every second.

22. Workflow U: AI-Automated Social Wall

This is a fantastic idea. You are essentially proposing an "AI-First Content Moderation Pipeline."

Instead of a human manually reviewing 500 photos a day, you delegate that authority to the Gemini API (specifically Gemini 1.5 Flash, which is multimodal, incredibly fast, and cost-effective for high-volume tasks). This changes the Social Wall from a "Manually Curated" feature to a "Self-Driving" feature.

Here is how we architect "Gemini as the Social Manager" for SHoRE Fest.

1. The Trigger (Ingestion)

• The backend fetches the latest 20 posts tagged #shoremachao from Instagram.

2. The "Consultation" (Gemini API Call)

• Instead of saving these immediately to the DB, your server sends the Image and the Caption to Gemini.
• The Persona: We tell Gemini it is the "Chief Brand Safety Officer" for a University Festival.

3. The Analysis (The Logic)

• Gemini evaluates the post against strict "College Fest Guidelines":
  • NSFW/Violence: (Built-in Safety Filters).
  • Substance Abuse: (Alcohol, smoking, drugs - usually strict for colleges).
  • Sentiment: Is this hate speech, sarcasm, or a complaint?
  • Relevance: Is it actually about the fest, or just spam using the hashtag?
  • Quality: Is the image too dark/blurry to look good on the homepage?

4. The Verdict (JSON Output)

Gemini returns a structured decision:

{
  "decision": "APPROVED",
  "confidence_score": 0.98,
  "reason": "Clear image of students dancing, positive caption, no brand risks."
}

OR

{
  "decision": "REJECTED",
  "reason": "Contains alcohol bottles in background."
}

5. The Action

• High Confidence Approval (>0.9): Auto-publish (Status: Live).
• Rejection: Auto-delete.
• Unsure (0.5 - 0.9): Send to "Manual Review" queue for a human to check (Status: Pending).

The "Prompt" Engineering

To make this work, we don't just ask "Is this bad?" We give Gemini a rubric. Here is the system instruction you will use in your code:

System Prompt for the API:

"You are the AI Content Moderator for SHoRE Fest 2026, a university festival. Your job is to filter user-generated Instagram content for the public website.

Analyze the provided Image and Caption.

Rejection Criteria (Immediate Fail):
1. Nudity, violence, or sexual content.
2. Alcohol, drugs, or smoking paraphernalia.
3. Hate speech, bullying, or profanity in the caption.
4. Competitor university logos prominent in the frame.
5. Spam (crypto ads, unrelated content).

Quality Criteria (Soft Fail):
1. Image is extremely blurry or dark.
2. Caption contains negative sentiment about the university.

Output Format (JSON Only):
{
'status': 'APPROVED' | 'REJECTED' | 'FLAGGED',
'reason': 'Short explanation',
'tags': ['happy', 'concert', 'food']
}"

Why this is better (and safer)

1. Speed: Humans sleep; Gemini doesn't. A post tagged at 2 AM gets approved at 2:00:05 AM.
2. Scale: If you suddenly get 5,000 posts during the "Pro-Show," a human moderator would drown. Gemini scales infinitely.
3. Cost: Gemini 1.5 Flash is extremely cheap. Analyzing 1,000 images would cost pennies.

Updated Database Schema for AI Moderation

The "Fail-Safe"

We must assume AI isn't perfect.

• The "Kill Switch": If a bad post does get through (AI hallucination), the Admin Panel must have a "Panic Delete" button that removes it instantly and bans that Instagram user handle from future auto-approvals.

24. Workflow V: Partner Engagement (Sponsorship) New

Goal: Automate sponsor acquisition and display value metrics publicly to build trust.

V1. The Public Partner Page (/partner)

• Actors: Potential Sponsors, Sponsorship Team.
• Components:
  • Marquee: A scrolling list of Past Sponsors (Logos fetched from DB).
  • Demographics Board: Data visualization showing "Last Year's Footfall", "Student Demographics", and "Social Reach" to prove value.
  • Deliverables: List of perks current sponsors get (Stalls, Branding, etc.).

V2. The Inquiry Loop

• Action: Partner clicks "Become a Sponsor".
• Input: Fills Contact Form (Company Name, POC, Budget, Expectations).
• Response:
  • System saves inquiry to DB.
  • System triggers Auto-Reply Email: "Thanks for reaching out! Our team will contact you shortly."

V3. Admin Management (Sponsorship Head)

• View Responses: Head opens Admin Panel → "Sponsorship Inquiries" to see list of interested brands.
• CMS Updates:
  • Head can update the Demographics numbers (e.g., if footfall expectation increases).
  • Head can update the Contact Form fields if requirements change.
  • Head can upload new Sponsor Logos to the Marquee section.

Phase Completion

We have now mapped 22 distinct workflows.

1. Core: Registration, Payment, Ticket Generation (Crypto), Access Control (Atomic).
2. Ops: Accommodation, F&B, Events, Competitions (Check-in/Result).
3. Admin: IAM, Analytics, Non-GITAM Verification, Support.
4. Marketing: Mystery QR, Instagram, Artists, Countdown, FAQs.

This is a complete functional specification.

Architectural Style: Modular Monolith

We will avoid the complexity of Microservices in favor of a Modular Monolith hosted in a Monorepo.

Repo Structure (TurboRepo):

• apps/web: Next.js (Admin Dashboard + Public Website)
• apps/api: Express.Js (The Unified Backend)
• apps/scanner: Flutter (Mobile App)
• packages/db: Prisma Schema (Shared types)
• packages/ui: Shared Design System (Tailwind components)

Why this wins:

• Type Safety: We can share TypeScript interfaces between Backend and Frontend instantly.
• Scaling: We handle 15k users by adding more instances of apps/api behind a Load Balancer, not by splitting the code.

Technology Stack Selection

Philosophy: Reliability > Innovation. We are building for 15,000 users, not a hackathon prototype. The stack prioritizes Offline-First capabilities and High Concurrency.

Core Infrastructure

• Cloud Provider: Google Cloud Platform (GCP) (Leveraging existing familiarity).
• Database: PostgreSQL 16+ (Hosted on Cloud SQL).
  Why: Relational integrity is non-negotiable for payments and room allocation.
• Caching & Queues: Redis & BullMQ.
  Usage:
  • Caching IAM permissions, counting live check-ins, holding webhook bursts.
  • Handles payment bursts. Backed by Redis. Native to Node.

Backend (The "Brain")

• Runtime: Node.js (v20 LTS) with TypeScript.
• Framework: Express.js or NestJS (NestJS recommended for structured, enterprise-grade architecture).
• ORM: Prisma or Drizzle. (Prisma is safer for atomic transactions).
• AI Integration: Google GenAI SDK (Gemini 1.5 Flash).

Frontend (The "Face")

• Web Portal (Admin/User Dashboard): Next.js 14 (App Router).
  Why: SEO for the public site, Server Components for the Admin dashboard performance.
• Mobile Apps (Scanner & Attendee): Flutter.
  Why: Superior access to native hardware (Camera/NFC) and better performance for the "Offline Crypto Engine" compared to React Native.

Critical Libraries

• Cryptography: libsodium or tweetnacl (for Ed25519 signing/verification).
• Queues: BullMQ (Redis-based job queue for handling payment webhooks).
• Validation: Zod (Runtime schema validation).

API Endpoints Specification

Authentication & IAM

Core Events & Registration

Access Control (The "Gatekeeper")

Logistics (Hospitality & F&B)

Partners & Sponsorship (New)

Engagement (Social & Mystery)

Operations (Support & Config)

The Queue Strategy (Handling the Load)

We will use BullMQ to decouple "User Actions" from "Heavy Processing".

Scenario: Payment Webhook Burst (2,000 req/min)

1. G-Events Webhook hits POST /webhook.
2. API: Pushes job to payment-queue (Time: 2ms). Returns 200 OK.
3. Worker: Picks up job.
4. Validates Signature.
5. Updates DB (Paid).
6. Generates QR Seed.
7. Sends Email.

Result: The API never crashes, even if the Email service is slow.

Environments Strategy

A. Local Development (Laptop)

• DB: Local Docker container.
• Data: Seeded with 10 fake users.
• Focus: Writing code.

B. Staging (The Rehearsal)

• URL: api-staging.shore.in
• DB: Cloud SQL (Staging Instance).
• Data: Anonymized copy of production data (or massive fake data).
• Purpose:
  • Load Testing: We attack this env with scripts to break it.
  • UAT: The Hospitality Head logs in here to "practice" assigning rooms.

C. Production (The Show)

• URL: api.shore.in
• DB: Cloud SQL (Production High-Availability Instance).
• Data: Real User Data.
• Constraint: Read-Only access for developers. No manual DB edits allowed.

Day 1 Launch Plan (Deployment Strategy)

Target: Zero Downtime, High Availability.

Phase 1: The "Soft" Freeze (T-Minus 48 Hours)

1. Code Freeze: No new features. Only critical bug fixes.
2. Database Snapshot: Create a full backup of the Pre-Prod DB.
3. Load Testing: Run k6 script to simulate 5,000 concurrents hitting /events and /gate/verify.
4. Cache Warm-up: Pre-load the Redis cache with Event Details, FAQs, and Role Permissions.

Phase 2: The Infrastructure Setup (T-Minus 24 Hours)

1. Scale Up: Increase Cloud SQL instance size (High CPU/RAM) to handle concurrent writes.
2. Replica Setup: Spin up 2 Read Replicas for the database (offload Analytics/Dashboard queries).
3. Worker Nodes: Scale up the BullMQ worker instances to handle "Payment Burst" traffic.

Phase 3: The "Go Live" (Hour 0)

1. Feature Flag Check: Ensure registrations_open is FALSE initially.
2. Deploy: Push Docker containers to production (Cloud Run / GKE).
3. Sanity Check: Admins perform a "Test Loop" (Register -> Pay -> Generate QR -> Scan) on Production.
4. The Switch: Admin toggles registrations_open to TRUE.
5. Marketing Blast: Email/SMS sent to students.

Phase 4: The War Room (Monitoring)

1. Screens: Display Grafana Dashboards showing:
   • API Latency (Alert if > 500ms).
   • Error Rate (Alert if > 1%).
   • Queue Depth (Are payments piling up?).
   • Social Wall AI Rejection Rate.
2. Contingency:
   • DB High CPU: Switch Analytics dashboard to read from "Cache Only."
   • Scan Failure: Broadcast "Switch to Offline Mode" notification to all Scanners via FCM.