How Sourabh Garg Rebuilt Pizza Hut's Real-Time Store Data Systems

Every restaurant in a global chain has a small data problem. A price changes at headquarters, a menu item is added, a promotion begins, and that change has to reach the point-of-sale system in each store quickly and without error.

Multiply one store by tens of thousands and the problem stops being small. For most of the last decade, a large part of how Pizza Hut has solved it has run on architecture designed by Sourabh Garg.

Garg is a Senior Technical Architect at YUM! Brands, working from Plano, Texas, where he has led in-store and retail technologies for Pizza Hut since 2015. In practice, he says, this means he owns the design of the systems that carry data between the company's restaurants and its central platforms.

That work never appears on a menu or in the app a customer opens. It runs underneath all of it, and when it breaks, the break shows up as a register with the wrong price or a store that cannot take an order.

The restaurant business has spent the past few years moving this layer to the middle of its operations. More than half of American restaurant brands now take at least a quarter of their sales through digital channels, which means the software connecting stores to headquarters carries real money and cannot be allowed to drift.

Keeping it steady is Garg's job.

The Polling Problem He Solved

The system Garg set out to change had an inefficiency built into its design. Each storefront checked a central database for updates on its own schedule, polling it again and again to ask whether anything had changed.

Across thousands of stores, that produced a steady stream of traffic that mostly returned the same answer, and it introduced a delay, because a store that checks every few minutes is always a few minutes behind whatever moved.

'Every storefront was hitting the database on its own clock,' Garg says. 'Multiply that by thousands of stores and you get a system that spends most of its energy answering the same question over and over.'

His replacement is an event-driven pipeline he calls SWIFT.

Built on Amazon Web Services with Lambda functions and S3 storage, it notifies the database only when data actually changes, instead of letting every store interrogate it around the clock. The traffic that carried no new information disappears, and the gap between a change at headquarters and its arrival at the register closes.

Garg validated the design across 5,500 U.S. Pizza Hut storefronts under the high-concurrency transaction loads a chain generates at dinner rush, and it then fed into rollout planning for YUM! Brands' global system of more than 63,000 restaurants.

He built monitoring on Splunk into the pipeline as well, so the team could watch where messages moved and where they stalled across storefronts on several continents. In a system that spans that many regions, a fault in one place cannot be allowed to spread into the others, and the monitoring is what makes an early fault visible.

Connecting the Workforce Systems

The pipeline was one of two large pieces of restaurant infrastructure Garg took on. The other was HotSchedules, a third-party labour scheduling and forecasting platform that had to be integrated into the same 5,500 storefronts without disturbing the systems already running in them.

Labour scheduling looks routine from the outside and is anything but. A restaurant forecasts demand, matches it to the staff it rosters, and feeds real store data back into the model so the next forecast improves on the last.

When the platform doing that belongs to another company, the integration has to move data cleanly between the outside system, the restaurant's own platforms, and the enterprise reporting behind them, and it has to do so reliably enough that a manager trusts the schedule the software hands back.

Garg built the connection with secure API gateways and synchronisation adapters, and tested it using an approach he calls Shift-Left, catching defects in development rather than discovering them in production.

The stakes are practical. Done poorly, that kind of integration reaches straight into employee scheduling, payroll accuracy, and forecasting. Done well, it disappears into the daily running of the store, which was the point.

Moving Live Systems Without Stopping Them

A second category of Garg's work has been modernising older infrastructure while it stayed in use. He led the containerisation of several back-of-house applications, including the store update service, the food management system, and the DragonTail and Tomcat platforms, and supported migrating their terminal environments from one version of Ubuntu Linux to a newer one across the estate.

He also designed the migration workflows that moved employee records, time punches, schedules, and transaction history between systems as the company shifted from its eRestaurant database to a new food management platform.

Migrations of that kind are where a great deal goes wrong quietly: a mismatched record in one place, a dropped punch in another, each surfacing later as a payroll error or a broken report that someone has to trace back.

None of it could be done by taking the restaurants offline. The systems had to keep running while their foundations changed underneath them.

Changing a system nobody is using is straightforward. Changing one that thousands of stores are transacting on at that moment, without any of them noticing, is the constraint that separates enterprise infrastructure work from a clean build.

The Architect's Role

What links these projects is the level of decision-making they demanded.

Garg was not implementing a specification handed down to him. He set how the systems were structured, made the calls on data integrity, transfer efficiency, and how the parts fit together, and carried the consequences when a restaurant network depended on the result.

'An architect's job is to decide what not to build as much as what to build,' Garg says. 'The wrong structure still works on the day you ship it. It fails you two years later, when it is expensive to change.'

That distinction, between owning a system's design and executing someone else's, separates the senior architect from the engineer working to a ticket. It is more commonly the province of technology leaders than of routine engineering roles, and it is the level Garg has worked at across a career spent in retail, banking, and federal systems.

Across the pipeline, the scheduling integration, and the platform migrations, he has held the design end of systems that reach tens of thousands of restaurants in more than 150 countries.

Each one asked the same thing of him, and it is among the harder things to do in enterprise software. He had to rebuild systems that were already carrying real business, while they carried it.