doc:001 · profile
I help teams fix distributed search systems under pressure: production incidents, cluster instability, and relevance that’s quietly gotten worse. I also do the calmer work that stops the next incident from happening: architecture reviews, scaling plans, relevance programmes. For more than five years I’ve run search systems and clusters at scale, from first diagnosis to a fix in production.
doc:002 · stack
Apache Lucene and the systems built on it: Solr, Elasticsearch, OpenSearch, and Lucidworks Search. I work on commit and merge strategy, shard routing and distributed query execution, caching, query parsing and scoring. Also the vector and hybrid search features layered on top.
doc:003 · contact
Remote-first, hands-on. Every engagement starts with a free assessment: describe the problem by email and you’ll get an honest read on what is likely wrong, whether I can help, and what fixing it would involve, no commitment. From there, work ranges from a short diagnostic sprint to longer support through a migration or scale-up.
doc:004 · service
Production incidents, replication failures, indexing pipeline problems, capacity and shard layout. Root-cause analysis with runbooks that prevent the same failure from coming back.
doc:005 · service
Index design, cluster sizing, upgrade planning, migration from single-node to distributed. Honest assessment of whether the current setup will hold as data and query volume grow.
doc:006 · service
Diagnosing poor result quality, retuning scoring and field weights, building relevance models tailored to how users actually search. Building a baseline so improvements can be reliably measured, not eyeballed.
doc:007 · service
Combining lexical and semantic search correctly. Scoring normalisation, index architecture for multi-tenant setups, embedding dimensionality tradeoffs. Diagnosing why hybrid search degrades as data grows.
doc:008 · engagement · solr
A digital asset platform on standalone Solr, planning a move to a distributed setup while scaling from 22M to 82M documents. The existing access-control model relied on a per-document join that would not hold at that size. The work covered redesigning how authorisation was indexed, planning the collection topology and sharding, and tuning vector search for the new scale.
doc:009 · engagement · solr
A search cluster was under unnecessary strain during catalogue updates, causing query slowdowns that users felt as sluggish search. Routine updates were rewriting far more of the index than had actually changed, and background maintenance jobs were competing with live search traffic for the same resources. Targeted configuration changes, rolled out incrementally with no service disruption, cut the extra load those updates put on the cluster by more than three quarters, ending the slowdowns.
doc:010 · engagement · solr
A high-traffic retailer running search across dozens of regional markets had daily latency spikes that coincided with catalogue updates. The cause was a configuration gap rather than a capacity problem: search components were competing with the indexing process for the same resources. Fixes delivered across all regions eliminated the daily spikes, along with a fix for a cache misconfiguration that had been quietly degrading performance since launch.
doc:011 · engagement · solr
An industrial parts e-commerce platform on Solr was hitting performance and stability issues as traffic grew. Distributed queries weren’t routing sub-query stages across replicas, concentrating load on individual nodes. autoCommit on the catalogue collections was set too aggressively, forcing constant segment merges on every catalogue update, while nested JSON facets ran against unlimited result sets, making some queries prohibitively expensive. Retuning all three removed the hotspots and cut p99 query latency by over 60%.
doc:012 · engagement · solr
After a production incident, query analysis found that common customer searches were unintentionally matching a large share of the catalogue, in some cases nearly 20% of 3.2 million products, before relevance was even computed. Contributing factors were traced across configuration, indexing jobs, and schema design. Several fixes shipped within weeks, eliminating the over-matching and with it the query load that had triggered the incident.
doc:013 · engagement · opensearch
A service management platform moving into AI and agentic workflows, dependent on hybrid search for its RAG features. Search quality degraded as more tenants shared a single index and eventually broke, with the cause traced to scoring contamination across the shared multi-tenant index. The work covered diagnosing why lexical and vector matches were misbehaving, then delivering a remediation plan: separated lexical and vector retrieval, tenant-isolated scoring, and a relevance benchmark to measure quality against.
LuceneSolrElasticsearchOpenSearchLucidworks Search