perf: optimize Firestore read operations triggered by typesense indexer

[beastoin]

The ext-firestore-typesense-conversations-indexonwrite Cloud Run service fires on every Firestore document write, triggering read-back operations. Over a 6-day sample this generated 22.6M requests — the highest-volume service by far. Each write triggers reads that may be redundant if the indexer is re-reading data already available in the trigger payload.

Current Behavior

• Every Firestore document write triggers the typesense indexer Cloud Run service
• The indexer reads back the full document from Firestore on each trigger
• Rapid successive writes (e.g., conversation segments) each trigger independent read-backs
• 22.6M requests in 6 days from this service alone

Expected Behavior

The indexer should avoid redundant Firestore reads by using trigger payload data or caching, and debounce rapid successive writes.

Affected Areas

File	Line	Description
ext-firestore-typesense-conversations-indexonwrite	—	Cloud Run service triggered on Firestore writes
backend/utils/conversations/search.py	—	Typesense search integration
backend/database/	—	Firestore access patterns

Solution

Note: Solutions below are not verified by CTO — suggestions from infra analysis only. Open to deeper investigation and better approaches.

Audit whether the trigger payload already contains the document data (avoiding the read-back). If not, add a debounce/batch layer:

# Debounce: buffer writes for same doc_id, process once after 2s idle
cache_key = f"typesense:pending:{doc_id}"
redis_db.set(cache_key, timestamp, ex=5)
# Worker picks up after debounce window

Files to Modify

• Typesense indexer Cloud Run/Function configuration and source
• Firestore trigger setup

Impact

Reduces Firestore read operations volume and indexing load; no user-facing behavior change.

---

by AI for @beastoin