CAD 2.0 passed all 113 automated reliability and load scenarios in our latest run, on 23 October 2026. We run them again as CAD 2.0 develops. Here are the results, the setup they ran on and how we test.
Each area is a set of automated scenarios. Every result is checked against what actually landed in the database, not against what the till reported.
Normal trading with the store database up. The baseline every failure scenario is compared against.
The database service is stopped, or the network cable is pulled, while the till is trading.
The server is up but a sales or product table is locked — by a long report, a nightly backup, or another program.
The link to the database drops at every step of recording a sale — before a statement runs, and after it ran but before the reply arrived.
The real till screen in a browser while the database is slow, busy or gone, and after a crash.
Sales that need the store server's agreement are never queued — they are refused clearly when it cannot be reached.
The loyalty server drops after a voucher or points sale was approved.
Two tills, each with its own queue, selling at the same time while the server goes down, the link flaps, or a table is locked.
The item search popup by department, word and exact code.
A trading session with the store server unreachable in the middle of it. Sales before, during and after the outage are compared with what the server holds once the link is back.
Simulated tills each ringing sales back to back — scan every item, then finalise — with no pause between customers. Far busier than real cashiers, so these are ceilings, not a typical day.
| Tills | Sales / min | Finalise p95 | Finalise p99 | Scan p95 | Scan p99 | Sales reconciled |
|---|---|---|---|---|---|---|
| 5 | 2 241.6 | 54 ms | 64 ms | 36 ms | 47 ms | 2 251 |
| 10 | 2 488.7 | 116 ms | 144 ms | 65 ms | 80 ms | 2 506 |
| 25 | 2 620.3 | 301 ms | 375 ms | 147 ms | 175 ms | 2 664 |
| 40 | 2 520.7 | 600 ms | 749 ms | 267 ms | 354 ms | 2 600 |
| 100 | 2 479.6 | 1.6 s | 1.8 s | 663 ms | 904 ms | 2 650 |
p95 and p99: 95% and 99% of responses were at least this fast. Checked: every sale answered before the till's 25-second limit; every sale recorded exactly once; rand totals match to the cent. From 10 tills up, sales per minute level off while the time each sale waits rises. The database, the POS server and every simulated till shared one machine.
The till keeps scanning from its own product copy and queues each sale. When the connection returns, the till sends the queue by itself. In the lab, every sale was recorded exactly once, and the counts and rand totals matched what the till took.
No. Sales that need the server’s agreement are refused with a clear message while it can’t be reached. Nothing is saved or queued, and they go through normally once it’s back.
A write whose reply was lost is never blindly sent again. The sale is either completed or undone, and recorded once, with stock moved once.
In this run, 100 simulated tills sold at the same time with no pause between customers, on one AMD Ryzen 7 260, 16 logical cores, 16 GB RAM machine that also ran the database. 95% of sales were finalised within 1.6 s, and every sale was reconciled to the cent.
No. They show how CAD 2.0 behaved under the conditions on this page. Your hardware, network and trading pattern will differ, so we size each installation for the store.