Federated search: where unified results break
Federated search answers a single query across multiple systems at once: catalog, request database, file storage, external services. The query goes to all disparate sources in parallel, and the answers are merged into a unified result set.
It breaks on asymmetry: response time is determined by the slowest source, while the others wait the whole time.
While one segment responds several times longer than the rest, the user gets either a blank screen or half the results.
The second source of failure is data desynchronization: indexes update at different frequencies, and a document that has already been changed or deleted in the source system surfaces in the results.
The third is incompatible relevance scores. Each system calculates importance on its own scale, so when merged, a strong result from one source loses to a weak one from another.
Deduplication breaks next: one entity arrives from three places with different identifiers and takes the top of the results three times.
This is not fixed by “one big database,” but by a federation layer: a time budget per source, a partial response with explicit indication of non-responding systems, a cache for hot queries, and circuit breaking to an unstable node.
On top — score normalization and unified ranking (Elasticsearch as the search core), so that the order of results does not depend on who managed to respond first.
Outcome: the unified result set stops depending on the weakest participant, and the user sees exactly what they got and what is missing. We break down how this is structured and how it is closed in practice.
What changes after implementing a unified access layer
A unified access layer sits between user scenarios and disparate systems: document database, task storage, catalog, external reference data. The query goes to all sources in parallel, results are brought to a common schema, and they are combined into one ranked result set.
Single entry point instead of manually traversing systems
Previously, an employee opened three or four systems and manually consolidated results, and some data was lost due to different search rules. Now the query goes to one point, and the layer itself decides which sources to query and how to match entities.
We build such schemes on Elasticsearch with federated querying and a shared synonym dictionary — ranking does not depend on where the document is stored.
The load on sources drops: repeated traversals are replaced by a cache for hot queries and targeted index lookups. Peak hours no longer turn into a queue.
How the effect is measured: response time and share of complete result sets
We measure the effect before and after implementation, on the same set of test queries. The key metrics are 95th percentile response time and the share of complete result sets: queries where all relevant documents from the control list were found. We compare manual traversal, direct source polling, and operation through the layer.
In practice, response time decreases from several seconds to fractions of a second, result completeness goes from partial to near complete, and source requests drop severalfold.
Separately, we record eliminated failure classes: mismatched results between systems and failure of one source that previously broke the entire result set.
Methods of combining sources: comparison table
There are three ways to combine multiple sources: query them at request time via a search intermediary, pre-collect content into a single index, or cache results and periodically mix in fresh data.
The choice is determined not by convenience, but by how many sources there are, how often data changes, and what response time is considered acceptable.
| Option | When it fits | Limitations |
|---|---|---|
| On-the-fly combination via a search intermediary | Sources change daily, there are few of them, result freshness matters | Final response time equals the slowest source; some queries do not complete within the allotted time |
| Preloading into a common index | The dataset is stable, end-to-end ranking and filters across all sources are needed | Reindexing lags behind edits, storage volume grows, full rebuild is more expensive |
| Result cache | Many repeated queries, sources handle load poorly | Data becomes stale between updates; reset logic based on actual changes is needed |
| Hybrid: index plus on-the-fly supplemental query | Large stable datasets and small rapidly changing sources | Two processing branches: harder debugging, monitoring, and diagnosis of empty result set causes |
When on-the-fly combination is justified
If an edit in a source must appear in results within minutes, and the source returns a structured response, the intermediary queries it directly and does not store a copy.
The trade-off is that latency is determined by the slowest participant, so a maximum wait time and a partial response rule are defined in advance: if one source does not respond in time, results are assembled from the rest instead of returning an error. The result cache here has a short lifetime and is reset based on a data change signal.
When preloading is needed
For large datasets requiring end-to-end ranking and shared filters, content is transferred into a single index on a schedule. Response time becomes predictable and independent of source availability, but a gap appears between an edit and its visibility.
It is reduced by update frequency and targeted reindexing of changed documents instead of a full corpus rebuild.
Stages of implementing federated search
Federated search starts not with code, but with source inventory. Until it is clear which systems cover the main share of queries and how permissions are structured, any scheme remains a hypothesis. Below is the order of work we go through on each project.
- Source audit. Inventory of systems: volume, update frequency, field formats, access models. The output is a matrix: what each source returns, with what latency, and by which keys it is matched with the others.
- Environment design. We decide where the combined index lives, what is updated by stream and what is queried on the fly, and how shared and restricted data are separated. We agree the design with system owners in advance.
- Query routing and permissions. Rules decide which subset of sources receives a query; access filters are applied when querying each source, not after merging results — this eliminates leakage through the aggregated result.
- Result quality validation. A reference set of queries, labeling of expected answers, measurement of completeness and precision per source — more below.
- Handover to operations. Update procedures, monitoring of source unavailability, support instructions, and connection points for new systems without rebuilding the environment.
What result quality validation looks like
We record reference queries — typical, rare, and deliberately ambiguous — and label what counts as a correct answer.
The run produces three numbers: the share of queries with a complete answer, the share of cases with correct permission-based filtering, and response time on a heavy slice. We investigate discrepancies down to the cause — routing rule, metadata field, or update lag. Otherwise result quality degrades silently.
Configurations, diagrams, and procedures you receive
After handover of the environment, your team keeps not presentations, but working artifacts: configurations, diagrams, and procedures by which the system can be developed and maintained without us.
Each document is tied to a specific node of the environment — it shows what to change when connecting a new source or changing access rules.
Data flow diagrams and source map
- Source map: connection type, data owner, update frequency, export restrictions.
- Query flow diagram — from entry point to result merging, including where duplicates are discarded.
- Indexing diagram: what goes into the index, how often it is rebuilt, where state is stored.
- Environment configuration: search profiles, field weights, match thresholds, per-source timeouts.
- Degradation diagram: which source is disabled first and what the user sees when it is unavailable.
Access policies, roles, and logs
- Role model: who sees which sources and fields, how permissions are inherited.
- Rules for masking sensitive fields in results and exports.
- Query and administrator action logs: record contents, retention period, who reads them.
- Operations procedure: index rebuilds, connecting a new source, scheduled maintenance, incident response.
- Procedure for granting and reviewing access, including role changes or employee termination.
The package resides in your repository and is updated together with the environment — at the next release, the logic does not have to be reconstructed from memory.
Case study: combining six disparate systems
Before implementation, six sources — accounting system, document storage, mail archive, request database, policy portal, and industry reference — each had its own search.
An employee repeated a query four to six times and manually compared results: response time for such composite search was measured in minutes, and the share of successful first-attempt queries stayed around 40% — some documents simply did not make it into the result set.
We built a federated layer on top of Elasticsearch indices: a single entry point, query parsing into entities, parallel source polling with time limits, and result merging by relevance.
We do not bypass permissions — each result is filtered by the user's access rights from the source system, so the unified result set contains no documents the user is not entitled to.
What changed on the sources' side
Federation would not have worked if the sources had remained as they were.
In the accounting system and request database, change logs appeared, and the index updates incrementally rather than by nightly rebuild — the discrepancy between the system and the results decreased from a day to minutes.
In the document storage, unified attributes were introduced: type, department, validity period. In the reference, a dictionary of synonyms and industry abbreviations was added, so that “supply agreement” and “supply” lead to the same set.
Result: response time 1–2 seconds instead of minutes, share of successful queries 89% versus 40%, in 84% of cases one wording is enough. The flow of “where is this stored” questions stopped being a separate area of support work.
“Previously, every attempt to bring the databases together ran into access rights. Here the layer works on top of the systems without breaking anything, and rollback to the previous search scheme remains possible,” — the domain owner.
What to do if sources cannot be stopped?
No one takes a working system out of operation for a new search, so connection is built on top of existing services in read-only mode. Our environment accesses sources the same way any of their regular consumers does and does not claim write access anywhere.
Access rights are granted for reading: a separate account, replica, or regular export — at the source owner's choice.
Even if there is a configuration error, we physically cannot change data in the source system, so risk to it is limited to reading rather than corruption of content.
The environment expands in stages. First one source is connected — it is used to check result completeness, normalization quality, and behavior under load.
The next is added only after the previous one produces predictable results, and each step can be rolled back separately without affecting already working connections.
Compatibility is handled by a normalization layer: different data schemas, field formats, and reference books are brought to a common form, while the source remains the owner of the content.
Any source can be excluded from the environment at any moment — the remaining connections continue to work as before.
Reads are distributed so as not to compete with production queries: traversal goes in batches, in low-load windows, with limited parallelism.
No downtime occurs either at start or when adding new sources — search expands as readiness allows, and services continue to operate normally.
Technical concerns about combining sources
Five questions most often raised at the evaluation stage. We answer them before start: these decisions determine how the system behaves in operation, not just in a demonstration.
How are permissions separated if role models differ?
The source itself checks permissions: the query is sent with delegation, not by filtering the finished result. In the common model we only consolidate matching roles; the rest is local policy.
What happens if one source is unavailable?
The result set degrades partially: the others respond, and the response shows which data was not included. The query is retried with increasing delay; on sustained failure, the source is temporarily removed from polling.
How much work will a new source add?
Connection is a connector and a schema description: search fields, entities, applicable permissions. The core does not change, but reverse mapping to the original source is needed so the user lands on the original.
How are different data formats combined?
We bring them to a unified contract: text, metadata, permissions, link. Search runs over the normalized view, while the original in the source remains the point of truth — in case of discrepancy, it wins.
Will search put a load on the sources?
Requests are read-only, with a limit on concurrent queries and a priority queue. Interactive queries overtake background traversals, and repeated ones are absorbed by cache.
Let's discuss your source consolidation task
In the first conversation, it is more important for us to understand how your sources are structured than to show a ready-made solution.
30–40 minutes with an engineer responsible for data is enough to outline the boundaries of the environment and come back with a timeline estimate and work plan.
- Which systems already exist — catalogs, databases, file storages, external services — and which of them must be included in the unified result set.
- How access is structured: whose permissions are inherited in search, where field masking is needed, whether there are requirements for a query log.
- By what attribute documents from different sources are matched: a unified identifier, update procedure, duplicate merge rules.
- What we consider result quality — the share of relevant hits in the top, result completeness, acceptable query response time.
- Pilot environment: which two or three sources we connect first, on what data slice we test, and by which metric we accept the result.
- Implementation plan: connection sequence, extension points for new sources, who on your side accepts the stages.
- Post-launch support — monitoring source availability, updating schemas, rollback if quality degrades.
After the conversation, we send the pilot environment composition, implementation plan, and timeline estimate by stage. Describe the task in two or three paragraphs — we will come back with an estimate and architecture proposal.
