What does a core search API layer own, and why put one between product teams and Elasticsearch?

What Zalando has published. Its Elasticsearch upgrade post names the main application that talks to Elasticsearch: Origami, quoted from its internal description as "the Zalando Core Search API", providing "a powerful information retrieval language and engine" that integrates microservices built by the search department and is "the connector - coordinating all search intelligence to serve correct search results to customers". It builds on Elasticsearch and internal APIs for search and discovery, navigation and analytics. The post says it is written in Scala and large (443k lines across 846 files, including configs, tests and test resources), and that most of the upgrade work was migrating its Elasticsearch client. A later Zalando post on a search outage describes layers such as a query builder, a catalog API and a lightweight Search API in front of the cluster. The public posts do not map those names onto each other, so in an interview talk about responsibilities, not about which box is which.

Why have the layer at all.

1. One query language. Product teams express intent (text, filters, sort, page, market) and the layer turns it into Elasticsearch DSL. Mappings, analyzers and index names can change without touching every caller.
2. One client to upgrade. When the Elasticsearch client changes, as with the deprecated High Level REST Client in the upgrade post, one codebase changes. The REST compatibility mode and the three-way client and cluster test matrix described in that post are only practical because there is one caller.
3. Guardrails. The layer is where you enforce which fields may be aggregated, maximum size and pagination depth, timeouts, and terminate-after limits. The outage post's follow-ups (application-side query limits with dynamic thresholds, rate limits by client type) live naturally here.
4. Caller identity. It can attach X-Opaque-Id per calling service, so slow logs and the task API show who sent an expensive query.
5. Composition. Query understanding, retrieval, re-ranking, promotions and fallbacks are orchestrated with a latency budget per step, and with A/B variants of query shapes.
6. Load control. During incidents the presentation layers act as a control plane: fewer parallel queries per request, more caching for hot queries, cheaper ranking fallbacks, which is what the outage post describes.

The risks to name. A central layer can become a bottleneck for every product change and a single point of failure. Mitigate with clear extension points (configuration-driven query templates, feature flags), independent deployability, horizontal scaling, strict per-dependency timeouts, and ownership boundaries so teams are not blocked on one backlog.

Alternate interview scenarios