Inside fast-growing consumer platforms, the customer rarely exists as one coherent record. A growth team defines what counts as an active user one way, a fraud team defines it another, and a marketing team builds a third version for its own campaigns. Each definition is reasonable on its own. Together they pull the same customer in conflicting directions, and the cracks only show once the business tries to act on all of them at once. Poor data quality already costs organizations an average of $12.9 million a year, and inconsistency across siloed systems is the problem data teams rank as the hardest one to fix.
Rahul Narakula has spent his career on the unglamorous layer beneath those experiences: the data infrastructure that decides whether a platform actually knows its own customers. As a Senior Software Engineer focused on data at one of the largest local commerce and delivery marketplaces in the United States, he is the founding engineer and technical lead of the company’s unified customer knowledge platform, the central system that holds a single, governed view of consumers, merchants, and delivery partners. The system he designed now sits underneath personalization, fraud prevention, marketing, and advertising for an audience of tens of millions. It exists to answer one deceptively simple question reliably: who is this customer, right now?
When Every Team Owns a Piece of the Customer
The appeal of distributed ownership is obvious. Let each team model the customer attributes it understands best, and the organization moves quickly. At small scale this works fine. At the scale of dozens of product teams and thousands of customer attributes, it quietly breaks, because no two teams agree on what an attribute means, when it was last true, or whether it can be trusted for a decision worth real money.
Narakula’s response was to stop treating customer data as something each team produces in isolation. He designed the platform’s architecture from the ground up, including the entity-attribute model, the self-service authoring system that lets teams define attributes through configuration rather than one-off pipelines, and the full path from source tables to the systems that serve live traffic. The goal was a single source of truth that every team could read from and contribute to without forking the definition of a customer. Today dozens of teams across growth, fraud, marketing, advertising, and merchant and courier operations build on that foundation instead of around it.
“The hardest part was never the technology,” Rahul Narakula says. “It was getting an entire company to agree that the customer is one thing, defined once, and that everyone reads from the same copy.”
Modeling Identity Across a Marketplace
A marketplace is harder to model than a single-sided product. It has at least 3 kinds of participants, consumers, merchants, and the people who fulfill orders, and the relationships between them carry as much meaning as the participants themselves. A consumer who orders from one merchant every week is a different signal than one who has tried 50 merchants once each. Most centralized data systems are built around a single key, one row per user, and simply cannot express those relationships.
To handle this, Narakula designed and led the platform’s move to a multi-key entity model, the first of its kind at the company. Instead of forcing every record into a single identifier, the model represents complex relationships directly, such as a specific consumer interacting with a specific merchant or store. That change extended the platform from a customer database into something closer to a map of the marketplace, and it made attributes about pairs and groups, not only individuals, available to the teams that need them. The historical snapshot system he built alongside it lets those teams reconstruct what was true at any past moment, which matters when a fraud investigation or a billing dispute hinges on the state of an account weeks ago.
“Single-key models feel clean until the business asks a question about a relationship,” Narakula explains. “Then you either rebuild the foundation or you keep bolting on workarounds that nobody trusts.”
Moving Data in Real Time, Without Breaking Trust
Speed is where most data platforms quietly fail. A customer attribute that is correct 12 hours late is useless for stopping a fraudulent order or honoring a time-sensitive promotion. The stakes are not abstract. Consumers reported losing more than $12.5 billion to fraud in 2024, a 25% jump in a single year, and the systems that catch that activity depend on customer signals arriving in seconds rather than hours.
Narakula built the streaming export layer that carries attribute data from the platform’s source of truth to the systems serving live traffic, along with a topic strategy that separates high-priority data from routine updates so the most important signals are never stuck behind a backlog. The result was a sharp drop in how long it takes new data to become usable, and a marked reduction in the on-call incidents that used to follow every traffic spike. For the teams running fraud checks and eligibility decisions, that difference is the gap between catching a problem and explaining one after the fact.
“Real-time is a promise, not a feature,” Narakula notes. “The moment a downstream team stops believing the data is fresh, they start building their own copy, and you are back to the problem you set out to solve.”
Turning Data Quality Into an Enforceable Contract
Trust in data is usually treated as a feeling rather than a guarantee. Teams assume a number is right until something breaks, then spend days tracing where it went wrong. That model collapses once machine learning, fraud scoring, and personalization all draw from the same attributes, because a silent error no longer affects one report. It propagates into thousands of automated decisions before anyone notices.
Narakula authored the platform’s data quality framework and built it into the pipeline rather than attaching it afterward. The system validates attributes before they merge into the source of truth, watches for anomalies after they land, and lets teams write custom rules for the data they depend on most. Above that sits a tiering framework with defined service levels and data contracts, so the attributes feeding high-stakes decisions carry stronger guarantees than the ones feeding a dashboard. The approach proved general enough that other teams across the company adopted the same validation and anomaly-detection patterns for their own systems.
“You earn trust by making quality boring,” Narakula observes. “It should be enforced automatically, long before a human would ever think to check.”
What a Single Source of Truth Makes Possible
The payoff of getting this right is not internal tidiness. It is what the business can suddenly do well. 71% of consumers now expect companies to deliver personalized interactions, and a clean, current view of the customer is the precondition for meeting that expectation at scale instead of guessing at it.
The same foundation now supports work that would have been impractical before. Onboarding a new attribute that once took the better part of 2 weeks now takes a few days, and non-engineers can define what they need through self-service tooling in under an hour. The platform is also what makes the company’s partnerships with outside brands in ridesharing and streaming technically possible, by delivering the real-time, governed customer signals those integrations rely on to check eligibility and link accounts across platforms. Narakula’s current focus is pushing further into automation, using software agents to take over the repetitive onboarding and operational work that still consumes engineering time.
“The work is invisible when it goes well, and that is the point,” Narakula reflects. “If the customer never has to think about whether a platform knows them, somebody underneath made sure that it always does.”
