ADR 001 Typesense for DFL Search

ADR-001: Use Typesense as Unified DFL Search Engine

Status

Superseded 2026-07-31 by Azure AI Search. See Search-and-Retrieval.

Context

DEMI needed full-text and faceted search over DFL documents against a 10-second response target.

eagle-api already ran Typesense 30.1, deployed by docker-compose and Helm, with five collections (documents, projects, activities, notifications, document_chunks), a real-time MongoDB change-stream sync, PDF extraction and page-based chunking, a proxy that injected an allowed_roles filter, zero-downtime re-index by alias swap, and a frontend adapter in eagle-public. Reusing it meant no second service to deploy or operate.

Decision

DFL search used Typesense as its only search backend.

• The existing document_chunks collection took DFL metadata fields and facets: documentType, topics, orcsCode, visibility, holdState.
• The existing allowed_roles model carried DFL visibility.
• Change-stream sync indexed DFL documents as MongoDB created them.
• Typesense's built-in ts/e5-small embeddings on the content field supplied semantic search with no external API and no per-query cost, queried alongside keywords in one hybrid request.

Consequences

Typesense could not hold this corpus. Its indexed fields are RAM-only with no on-disk mode, clustering is replication rather than sharding, and its own sizing rule put the corpus at 17-26 GB of RAM against the 8 GiB ceiling of Container Apps Consumption. A larger container was not a lever.

The ts/e5-small embeddings that most of this decision rested on were never enabled, so the semantic half was never exercised. Typesense code and infrastructure were removed, and retrieval moved to lexical BM25 on Azure AI Search — see Search-and-Retrieval.