Question

---

Growth Truth: Handling the Referral Spike

When traffic spikes, what breaks first — routing, LLM quotas, or database write paths? Here is how we framed a real referral window against a stateless chat surface.

---

Headline traffic (GA4)

Figures below are from Google Analytics 4 (Marketing performance) for a fixed 28-day window. GA4 can revise counts slightly as sessions reconcile; we cite the exported values for this slice.

Field	Value
Date range	2026-03-06 → 2026-04-02 (28 days)
Active users	4,669
New users	4,500

Two different dials: GA4 answers “how many people touched the property in this window.” Product-side analytics (referral events, campaign attribution, Stripe-adjacent rollups) answer “how did growth mechanics behave?” They are complementary, not interchangeable — and GA4 active users are not the same thing as Firebase Auth sign-in counts unless you say so explicitly.

---

Stateless inference and where burst load lands

The app’s chat path is stateless for portfolio payloads (/api/ai/chat — see Part 1). Under spike load, stress concentrates on:

1. Edge / routing — session affinity is not the model; referral survival is. We 307 apex → www so ?ref= and cookies stay coherent:

// middleware.ts — canonical host: apex → www
if (host === 'pocketportfolio.app') {
  url.hostname = 'www.pocketportfolio.app';
  return NextResponse.redirect(url, 307);
}

1. Serverless limits — maxDuration = 30 on the chat route; streaming responses; provider rate limits.
2. Firestore — quota counters (aiUsage), analytics metadata (toolUsage), referralEvents — hot writes, not giant prompt logs.

Takeaway: stateless inference keeps the heaviest sensitive payload off disk; growth still needs solid indexes and realistic capacity planning for referrals and quotas.

---

What tends to fail first

1. Referral attribution (middleware, cookies) — if this slips, growth looks “direct only.”
2. LLM provider throttling or streaming failures.
3. Firestore write contention on high-frequency collections during campaigns.

---

Part 4 of Sovereign Engineering.

Read the full Sovereign Intelligence book or try the app.