ADR-0001. Ship search as a library of IGNIS components, not a standalone service

Field	Value
Status	Accepted
Date	2026-02-15
Deciders	@search-team
Supersedes	—

Context

• Search needs the same source data that already lives in commerce (products, merchants, categories, devices, sale-channels) plus pricing and inventory.
• A separate service would need its own DB connection, deploy, port, Snowflake worker id, and a duplicate copy of the CDC consumer + auth wiring.
• The query path is latency-sensitive and called from commerce's own entity controllers.
• Typesense + the Debezium connector are the only true external moving parts; the rest is in-process logic.

Decision

We will ship @nx/search as a library package that exports four BaseComponent subclasses (ApplicationSearchComponent, ApplicationEmbeddingConfigurationComponent, TypesenseSearchEngineComponent, ApplicationCdcComponent) plus a SearchableControllerMixin. The host service (commerce) registers them in dependency order; search has no application.ts, port, or DB schema of its own.

Consequences

Pros	Cons
Zero extra deploy/port/Snowflake; reuses host auth + DB	Search lifecycle is coupled to the host's
In-process SearchService calls — no network hop on the query path	Cannot scale the CDC consumer independently of commerce
One CDC consumer in the host, not a duplicate	Host bootstrap must register components in the right order
Mixin lets each consumer controller add /search with its own tenant scope	A second consumer would re-run the same CDC pipeline unless coordinated

Alternatives Considered

Option	Pros	Cons	Why rejected
Standalone search microservice	Independent scaling, clear ownership	Duplicate CDC consumer, own deploy/port/DB, cross-service auth	Disproportionate ops cost for POS scale
Inline search code directly in commerce	Simplest wiring	Not reusable, untestable in isolation, bloats commerce	Loses reuse + clean boundaries

References

• packages/search/AGENTS.md — component registration order
• Architecture