Blog
Your AI model works in the pilot. What’s harder to know is whether your data infrastructure can keep up once that model makes decisions against a continuously changing enterprise reality.
When a team runs an AI pilot, they track model metrics, such as accuracy, precision, recall, and inference time. The pilot works, the numbers look right, and the project gets the green light to go into production with the right compute and memory provisioned to run the model at scale.
What tends to surface later is that the production version of the same model needs a different kind of infrastructure than the one that worked for the pilot. It needs a data layer that can serve the enterprise reality of your business at the time of making every decision.
A fraud model with 99% accuracy still approves a fraudulent transaction if the account record it reads has already changed, but the change isn’t reflected in the data infrastructure. A personalization engine that picks the right product still loses the sale if the recommendation takes longer than the page load. A job scheduler assigns resources to a lower-priority job because the higher-priority job that came in after it hasn’t shown up in the queue yet.
In each case, the model did its job. The business outcome failed because the data underneath the decision was wrong, slow, or stale.
Operational AI runs as a continuous operating loop. Each decision starts from the authoritative state, the current record of what’s true for a customer, an account, or an order. The system assembles the relevant context around that state, makes a decision, and acts on it. The action has a consequence, and the consequence becomes updated state, which is where the next decision starts.
A companion blog, Six requirements for your data infrastructure, covers the technical infrastructure dimensions that keep this loop running. This post looks at the same loop from the business side. Where do the business outcomes break down, and how do you assess whether your organization is ready?
The Aerospike operational AI business assessment measures that readiness across six dimensions. Each one ties an infrastructure capability to a business outcome, and together they show whether your organization can sustain AI-driven decisions at the speed, scale, and reliability the business needs.
How much of the relevant context does each decision get to see?
Context breadth measures how much relevant context your system can assemble around authoritative state and deliver inside the decision window. A fraud model that sees only the current transaction misses the pattern across the last fifty. When a personalization engine sees only the current session, it misses the customer’s history across channels, and a recommendation limited to one product category misses the cross-sell.
With narrow context, the model still runs on time and still produces an output, but the decision is worse because it rests on an incomplete picture of the customer or the transaction.
PayPal’s fraud detection system assembles relevant context for each transaction from transaction history, behavioral signals, device records, geolocation data, and counter variables across sliding time windows. An entity graph links customers, devices, IP addresses, merchants, addresses, phone numbers, emails, accounts, and payment instruments, and three processes run against that graph at the same time (batch fraud ring detection, near-real-time event updates, and real-time multi-hop graph queries that finish in a few milliseconds).
Aerospike’s collection data types store daily aggregates as lists inside each record, so even the most active accounts need only single-digit reads instead of hundreds. PayPal increased the amount of data it evaluates by 10x while raising the share of fraud calculations completed within the required decision window from 98.5% to 99.95%. For the business, that means more transactions are scored within the 200ms time budget, reducing fraud exposure.
Can your business act on what it knows before the opportunity passes or risk escalates?
Decision speed is how long one turn of the loop takes, from the moment a business event happens to the moment the decision is carried out and its consequence recorded as the updated state. It covers far more than database latency, because it decides whether a fraud check finishes before the payment clears, a recommendation renders before the customer scrolls past, or a bid lands before the auction closes.
Every business has time budgets for its decisions. Some are explicit, such as a fraud evaluation that has to finish within 200 milliseconds. Others are implicit, since a delivery promise that takes ten seconds to compute has already cost the customer’s trust. Your data infrastructure must deliver authoritative state and relevant context inside that budget consistently, and that includes the slowest requests that averages hide.
Barclays’ fraud decisions sit in the card authorization path, with a detection budget of about 100 milliseconds. That window has to cover both pulling the data and running the model that scores it, so every millisecond spent on data retrieval is a millisecond the model doesn’t get. Dheeraj Mudgil, Vice President, Enterprise Fraud Architect at Barclays, puts the tradeoff in numbers. “When you only have about 100 milliseconds to detect fraud, even 40 milliseconds of database calls consume 40% of your detection budget.”
After consolidating onto Aerospike, Barclays now gets response times under 100 milliseconds at the 99.99th percentile, with latency 80% lower than on its previous system. For the business, that means fewer false declines on legitimate transactions, less stand-in processing, and faster authorization for customers.
When two parts of your business look at the same record, do they see the same thing?
Data integrity in operational AI is about consistency when reads and writes coexist against the same evolving reality. When multiple applications, models, or agents read and write the same records at the same time, the system has to guarantee that every reader sees the most recent write, so every decision starts from authoritative state. Without that guarantee, different parts of the business end up deciding on different versions of the same customer or order.
The consequences show up in everyday operations. A fraud system approves a transaction that the risk profile would have flagged, because the outcome of the prior evaluation hadn’t become updated state yet. Two agents promise the last unit of inventory to different customers. E-commerce delivery promises run into the same problem, because each one depends on inventory, carrier, and capacity data that changes all day.
Wayfair manages delivery promises across more than 30 million items from over 20,000 suppliers. Each time a truck leaves a warehouse or a carrier hits a capacity limit, every promise affected by that change has to update, and Victor Andreoni Paseka, Director of Software Engineering, Optimization & Planning Tech at Wayfair, says the clock is short. “If a truck door closes at a warehouse, we have about two minutes to reflect that change across our website.” A stream-join engine Wayfair built on Kafka and Aerospike recalculates only the promises each event affects, at millions of updates per second.
Customers see delivery promises built on authoritative state from the supply chain as it stands now, instead of a batch calculation from that morning. That matters because a broken delivery promise turns into a support call, a cancellation, or a lost customer.
Will your infrastructure sustain the same performance when the business doubles?
Growth capacity measures whether the continuous operating loop keeps its decision window as decisions multiply. A system that performs well at current volume but requires a redesign to handle next year’s traffic is not production-ready. It is a bottleneck waiting to arrive at the worst possible time.
This is intensity applied to infrastructure. As decision frequency, concurrency, and autonomous agents increase within each environment, the loop runs faster, and the data layer handles more reads and writes per second against the same records. A fraud system that slows down during peak shopping season exposes the business precisely when transaction volume and fraud risk are highest. The question is whether the infrastructure sustains the same decision window when the loop is running at 10x the rate.
Flipkart serves more than 200 million users and hit 95 million transactions per second during its Big Billion Days sale, one of India’s biggest shopping events. Through that peak, Aerospike kept serving search, product listings, and recommendations at sub-millisecond latency while traffic climbed far above normal levels.
Flipkart runs more than 170 Aerospike clusters year-round on bare metal under Kubernetes. Since that infrastructure went live, Flipkart has reported 100% availability and zero production incidents caused by the Aerospike Kubernetes Operator. Adding nodes adds capacity in proportion, without re-architecting, re-engineering a cache, or changing the data model, so the next Big Billion Days doesn’t call for a redesign.
Barclays saw the same thing with data growth. Its fraud data grew 10x in three years, from 3TB to more than 30TB, while throughput grew and tail latency stayed under 100 milliseconds at p99.99, all without a re-architecture or a cache overhaul.
If something fails tonight, does the business keep running?
A failure in the data layer does not just stop the continuous operating loop. It can leave the loop running on stale state, which is worse. A fraud system that fails over to a replica with a five-second lag is still scoring transactions, still approving them, still recording outcomes, but every decision in that window is based on state that is no longer authoritative. Stale fraud decisions approved during a failover look exactly like normal approvals until the chargebacks arrive.
Operational continuity measures whether the loop survives hardware failures, network partitions, data center outages, and traffic spikes without the authoritative state drifting from reality. The question is not whether the database recovers. It is whether the decisions made during the disruption were made on the current state.
AppLovin processes more than 70 billion ad requests a day, and each ad decision has roughly 50 milliseconds before the bidding opportunity expires. If the data layer goes down, AppLovin loses revenue on every impression it can’t serve. John Krystynak, AppLovin’s Founder and CTO, says the goal was “to be able to put a billion users into place and access any one of their records in a millisecond or two.”
AppLovin runs 35 production Aerospike clusters across 350+ servers and replicates data between sites with Cross Datacenter Replication (XDR). Those clusters hold about 250 billion records on more than 700 TB of disk and 70 TB of RAM, and roughly 4 billion records expire every day without disrupting ad serving. The system now handles more ads on fewer servers.
Because the architecture scales horizontally and has no single point of failure, ad serving, which is where AppLovin makes its money, keeps running through infrastructure events.
Can you afford to run AI at the scale your business requires?
Cost efficiency determines whether operational AI is economically sustainable at production scale. But in the continuous operating loop, cost isn't just about the invoice. Every copy, cache layer, and secondary database is a place where relevant context can drift from authoritative state. A cache miss returns stale data. A replication lag means one part of the system reads a version of reality that another part has already moved past. The cost is both financial and operational, because each additional layer is another place the loop can break.
An architecture that delivers the right performance but requires all data in DRAM produces costs that grow linearly with every new workload. A separate cache needs its own monitoring, failover, and consistency management. A second database exists because the first cannot serve reads fast enough. The engineering hours spent managing those systems don't appear on the infrastructure invoice, but they constrain the business just the same, and each one is a point where the next decision might read the wrong version of state.
Forter replaced a two-layer stack of Elasticsearch and Couchbase with a single Aerospike platform for real-time fraud analytics. The two-layer architecture was both a cost problem and a consistency problem, because the cache and database could disagree on the current state of a browsing session. Consolidating to one platform reduced servers from 178 to 50, cut hardware costs by 40%, and improved p99 latency 10x, from 13.3ms to 1.3ms.
Criteo made the same move. The company replaced 3,200 Couchbase servers with 720 Aerospike servers, a 78% reduction in server footprint, while processing 290 million queries per second at peak. Removing the separate cache and database layers did not just cut costs. It removed the places where relevant context could drift from authoritative state between a write and the next read.
At PayPal, the economics are equally clear. The prior in-memory system required 1,024 servers. Aerospike replaced it with 120, an 8x reduction, saving more than $9 million with an 80%+ reduction in total cost of ownership. The business can sustain fraud detection at 8 million+ database operations per second without a large increase in infrastructure cost.
Context breadth, decision speed, data integrity, growth capacity, operational continuity, and cost efficiency all depend on the data infrastructure underneath your AI, and together they decide whether the continuous operating loop holds up in production.
The enterprises in this post had to meet all six requirements at once, because a production loop breaks at its weakest dimension. Aerospike has spent years solving this class of problem in payments, AdTech, telecom, and e-commerce. AI is making it more universal across enterprises and more intense within each environment, so the same six dimensions now apply to businesses well beyond those industries.
The Aerospike operational AI business assessment scores your data infrastructure across these six dimensions. It takes five minutes. You get a personalized maturity score, a comparison against enterprises running at production scale, and specific recommendations for what to prioritize.
For a deeper understanding and more insights, explore these additional resources.
See more
Blog
Blog
Blog
Blog
