Decisions at the Speed of Memory: Hazelcast on IBM® LinuxONE 5
Network hops cost milliseconds; milliseconds cost money. Put data, compute, and AI on one platform, and both bills shrink, whether you run the platform today or are pricing the move.
A payment that clears late is a reportable SLA failure. A fraud score that arrives after authorization protects nothing. An offer that appears after the customer scrolls sells nothing. In payments, the decision window is regulated; in retail, it is competitive, with both measured in milliseconds.
Payment clearing, fraud and risk scoring, real-time pricing and offers: none of these has room for a slow answer. If you run them on IBM LinuxONE today, this is written for you. If you don’t, keep reading: compute and memory prices have shifted, and the acquisition math has changed with them.
Scaling out is the expensive way to slow down
The default answer to rising volume has been more x86: more servers, more clusters, accelerators added for scoring. Each round buys capacity and adds distance, with data in one tier, compute in another, models in a third. Every hop adds latency, and you buy more hardware to recover it. Physics does not negotiate; the estate pays.
The estate grows: servers, cores, the software licensed on those cores, power, floor space, the people to run it. Every record that leaves its system of record to be scored elsewhere widens the audit surface. Expensive to expand, hard to predict, harder to defend to a CFO or a regulator. The harder you push it, the more it pushes back.
Run the hot path where the data lives
Hazelcast inverts it: hold the operating data in memory, put distributed compute and stream processing beside it. Sub-millisecond from data to decision. On IBM LinuxONE Emperor 5, the hot path runs on the data serving platform itself, next to the systems of record already there: Oracle, EDB Postgres, MongoDB, CockroachDB. Records are cached, processed, and scored inside one security and compliance boundary. Nothing is sent off-platform; the data never leaves.
No rearchitecting: start with caching in front of an overburdened database. The database sheds its hottest reads, latency improves for the work that remains, and the next capacity expansion is deferred. Extend to payments, fraud, risk, and pricing in memory.
The arithmetic: more decisions per core
Throughput per core is the line item: most estate software is licensed by the core, and server count follows core count into power, space, and operations.
In the IBM Hazelcast Message Streaming performance and latency studies, Hazelcast delivered 16x more transactions per second (TPS) per core on enterprise-class IBM z16 than on a compared x86 system, and a 2.75x decrease in latency at the 99th percentile.¹
The number has a mechanism: the two architectures fit. Most distributed data software parallelizes by adding nodes, not by using a stronger core; extra per-core capability goes largely unused. Hazelcast works the other way. Genuinely multi-threaded inside each node and partitioned across nodes, it converts core strength directly into throughput and keeps scaling as cores are added inside the machine, before any network hop enters the path. In the studies, the IBM configuration ran 15 IFLs against 60 x86 cores. A 16x per-core advantage is what parallel software shows when each core has more to give; the 2.75x latency decrease is the colocation half of the same result.
The economics read: the same transaction volume from a fraction of the licensed cores and servers, network out of the critical path. The math is workload-specific, so measure it on yours; the direction is not subtle. Those results were measured on the prior generation of the platform.
Not on LinuxONE yet – the math moved anyway
The scale-out default was built on cheap, abundant x86. That assumption broke. AI demand re-priced everything distributed estates buy in bulk: memory first, then storage, accelerators, and servers. Costs and lead times keep climbing.
When every node costs more, the architecture that needs fewer of them wins. The per-core results above are an acquisition argument, not just a consolidation one: fewer cores means fewer servers, less memory, less energy. Run the TCO comparison at today’s procurement prices, not the prices the estate was designed around.
Memory became expensive; architectures that copy it became expensive faster. Replica copies, duplicated cache tiers, headroom on every node: scale-out burns the costliest input on overhead. Hazelcast spreads data instead of copying it, one in-memory layer doing the work of several duplicated tiers, fewer gigabytes as well as fewer cores, less cost base exposed to a volatile supply market. And the software estate carries over: the databases you already standardized on run on LinuxONE 5, with Hazelcast in memory beside them, one footprint instead of a multi-vendor sprawl.
Resilience you can take to an auditor
IBM LinuxONE 5 supports digital sovereignty with confidential computing and multi-tenant isolation, designed to keep sensitive data accessible within your designated boundaries with control and zero-trust. It prepares systems for tomorrow’s quantum risks with post-quantum cryptographic inventory tools, and it reduces power, space, and costs across the data center, freeing resources for your AI strategy. Add near-zero downtime and always-on availability, currently available through a worldwide supply chain, and the platform case writes itself. The architecture adds a layer of its own: the in-memory tier takes demand spikes before they reach the database, so peak load lands on memory, not on the system of record. Under the operational-resilience regimes, that is the evidence file. Hazelcast supplies the in-memory data and compute engine; LinuxONE 5 supplies the foundation, defensible to the CFO on cost and to the regulator on control.
The AI-era workload runs on the same platform
Optimizing the estate is the first return. The second is ML and AI in the transaction path.
The IBM LinuxONE 5 platform is designed to accelerate AI time to value in-transaction, where data lives, while reducing power and footprint. This is the ML banks and retailers already run in production: fraud, credit risk, and propensity models, scored inside the transaction. Hazelcast holds operating data and ML features in memory beside the IBM Telum II™ processor, so features reach the model without crossing a network. Telum features on-chip AI acceleration for real-time analytics and decision-making without extra hardware. Telum II boosts AI performance with 4x the compute power and connected processing clusters.² That is the difference between a score, or a price, that lands inside the window and one that arrives after it. Where generative AI becomes its own cost line, the same layer cuts it: semantic caching answers repeated questions from memory instead of paying the model twice. Inference cost and latency come down together, where the data is governed. The estate you consolidate is the estate your AI workloads inherit – added capability on an investment already made.
How it works, end to end
- A request arrives: a transaction, a query, an inference call.
- Hazelcast serves the data and features from memory on LinuxONE 5, no network round-trip.
- The model scores it in-transaction, where the data lives.
- The decision returns in the moment: a cleared payment, a flagged transaction, an offer priced while the customer is still looking.
- Sensitive data never leaves the platform.
The next step is a baseline, not a demo
Bring one workload (payment clearing, fraud scoring, real-time pricing, a cache under pressure) with its current x86 footprint, volumes, and latency SLA. Working with IBM and Hazelcast, we model throughput per core, 99th-percentile latency, and the consolidation or acquisition TCO on LinuxONE 5 against your numbers, not ours.
Learn more about Hazelcast on IBM LinuxONE at hazelcast.com, or contact Hazelcast to scope a workload assessment.
Learn more about the IBM LinuxONE 5 and the entire LinuxONE family, and read IBM’s LinuxONE 5 announcement at ibm.biz/zsystems.
¹ Based on the IBM Hazelcast Message Streaming Performance Study and the IBM Hazelcast Message Streaming Latency Study, comparing Hazelcast Enterprise 5.5.5 on enterprise-class IBM z16 (IBM Z Machine Type 3931 Max125) with a compared x86 system. Full study configurations and required disclaimers are published at https://hazelcast.com/wp-content/uploads/2026/07/Hazelcast-Performance-claims-on-IBM-z16-compared-to-x86.pdf. Results may vary.
² IBM, “Accelerated AI integration,” https://www.ibm.com/products/z/telum. Telum features on-chip AI acceleration for real-time analytics and decision-making without extra hardware. Telum II boosts AI performance with 4x the compute power and connected processing clusters.