.png){kind=logo}
The number Sohail Sayed keeps coming back to is one seventh. That is what the cost of search fell to after his team finished moving thousands of indexes across multiple regions onto a rearchitected platform, without, he insists, a single customer noticing the work was happening underneath them.
Sayed is a senior software engineer in one of the top software companies, where he owns the unstructured search area on a platform used by product teams across the company. Ask him what most engineers misunderstand about search at his scale, and he answers quickly. "Challenges are totally different at such a scale vs a few Azure Search Services," he says. "But new opportunities for optimizations also open up at this scale which are not available when individual tenants host their own services."
That is the crux of his argument, and it runs against how most search vendors pitch the problem. A single tenant running a single index, even a large one, is a tractable engineering problem. What Sayed handles is different in kind: petabytes of data spread across thousands of separate indexes, each belonging to a different customer, each with its own residency requirements, its own query patterns, and its own tolerance for a bad afternoon.
The migration is the story he tells to explain the difference.
His team had to move thousands of indexes, some of them multiple gigabytes on their own, from an older setup to a new one. Two failure modes bracketed the work. Move too fast and you disrupt live customer traffic. Move too slow and the project stretches into years, with new data pouring into the old system the entire time.
The fix was not a single clever trick. Sayed lists them in the order they mattered. Temporarily scale up compute for the migration window. Push harder during the customers' dark hours. Rewrite the hot paths for faster processing. Sequence the moves so a handful of enormous indexes could not eat every available core. Tune the parallelism until the throughput curve flattened.
They started on preview clusters, where the blast radius of any mistake was small. That decision paid off almost immediately. Query throttling issues surfaced there first, giving the team a real plan before touching the larger regions. "Issue like query throttling were identified early in preview clusters thus helping to get better plan for higher regions," Sayed says.
The hardest cases were the tenants that never stopped ingesting. A migration that has to catch a moving target does not converge on its own. Sayed's team wrote code that let those migrations reach
what he calls a logical end, at which point the system would flip over and handle the remaining delta through normal indexing. Without that change, some of the biggest customers would still be migrating.
Noisy neighbors are the other constant. In a shared search fabric, one tenant sending an unusual query load can starve the tenants sitting next to it. Sayed's approach starts before anyone gets provisioned. High-volume tenants are identified early through usage patterns and placed on their own search services. Low and medium tenants are grouped. Then the monitoring never really stops.
"Monitoring throttling and moving the noisy tenants to search services with higher resources is an ongoing process that continues post migration," he says. The topology is not a design that ships once. It is a design that keeps moving.
Sayed did not start in platform engineering. He spent his early career as a software consultant building applications for software companies, developed a speciality in SharePoint, and co-authored a book on SharePoint Foundation 2010. In 2014, he moved to the United States as a support escalation engineer for SharePoint development, which meant five years of watching customers hit walls in production. He crossed into product engineering in 2019 and eventually landed in his current work.
That biography matters for how he thinks about tenant isolation. Having spent years on the phone with customers when things broke, he treats disruption as the failure to avoid at almost any cost, even when it makes the underlying engineering harder.
The compliance surface adds another layer. Data residency laws vary by region, tenant isolation is not optional, and the platform still has to be reliable at a scale where a small percentage of failures becomes a large absolute number of angry users. Sayed frames this less as a constraint than as the reason interesting optimizations exist in the first place. When you control the substrate underneath thousands of tenants, you can partition data in ways a single-tenant deployment simply cannot.
The one-seventh cost reduction is the headline number, but Sayed is careful to point out that performance and reliability improved alongside it, because the team could finally put compute where it was actually needed rather than where it happened to be provisioned years earlier.
He is still moving tenants around. That, he says, is the part of the job that does not end.