[amluto]

To be fair, and I know nothing about Tesco’s actual stack, a large grocery chain needs to track their contracts with suppliers, track their inventory in each location and in transit, track what goods they want in which locations, understand which larger pallets and big boxes contain which goods, track things prepped in house, and also optimize what to move from where, to where, and when and how. The latter part probably uses some spiffy stack involving something like CPLEX or Gurobi, and it’s not running on their “1 computer” OLTP stack.

That being said, I don’t see what 40k servers is for unless the POS machines are thin clients that use a substantial fraction of a server each.

[alexvitkov]

If you're doing 10 million transactions per week (which is likely way more than what they're pulling) that's about 16 transactions processed per second. You can add inventory management, payroll management, you can run the company's email server, write all that in JavaScript, and you'll still have room to run a Minecraft server on the same laptop.

My point was not that running all that on one computer is a great idea, just that 40,000 servers for a CRUD application is way past what should be considered reasonable.

But even that's fine. I like computers, you can have 40,000 of them if you want, even if the only reason they exist is some guy's job security. However, you're insane if the guy keeping them running doesn't work for you.

[Anonbrit]

You're suggesting that all Tesco branches should do all the PoS transactions online to a single server?

Tell me you've never designed a system at this scale without telling me you've never designed something at this scale...

[IsTom]

Running it on a single laptop might be an exaggeration, but I can't imagine there's any essential complexity that requires more than a few dozen servers.

[alexvitkov]

No, I did not suggest that, in fact in the very comment you're replying to I said:

  My point was not that running all that on one computer is a great idea...

Regardless, if you want to strawman my passing remark, I'm happy to defend it.

Let's even say my numbers are wildly wrong, and they're processing 100x more transactions than what I claimed (which was already an overestimate). Tell me why you can't process 1600 transactions per second on one computer, especially for a country the size of the UK, where you would expect a ~15ms ping when talking to a server on the other side of the country.

[amluto]

I would expect outages when talking to a server on the other side of the country, and an outage preventing supermarket customers from checking out or supermarket staff from usefully restocking shelves would be a very expensive mistake.

A good system here will be distributed.

That being said, two servers (for redundancy) physically located at each branch ought to do the trick. Tesco has a bit over 5000 branches [0], so that’s 10k of the 40k VMWare seats right there. Throw in some extra seats so storage and compute can be separated at each location (maybe unnecessary but comes with some benefits) and so that there is still redundancy while a server or two at a site is being re-imaged and 40k seems about in the right ballpark even for a fairly lean implementation.

And, sure, all those on-site servers might be relatively inexpensive industrial units designed to tolerate a toasty, dusty, and occasionally damp closet that looks nothing like a tidy datacenter, but it still makes sense to run something like VMWare on them.

[0] https://www.tescoplc.com/investors/reports-results-and-prese...

[lillecarl]

It seems that you should work for Tesco, they would probably pay you well for reducing 40k VMs to 3.

[regularfry]

A long and storied history of nasty surprises has taught me to never underestimate the complexity of an unfamiliar domain.

In that sense I'm surprised it's only 40,000.

[Terr_]

Yeah, I'm pessimistically sure that there is other stuff, like:

* Checking whether each item scanned has satisfied a logical contract for a discount, some of which may be per-region, per-store, or even per-customer.

* If multiple exclusive coupons or deals are available, resolve the contradiction, preferably in favor of the customer.

* Check if any items or quantities of items require an ID to be shown before proceeding, and record information about the employee authorizing it.

* Update customer "rewards" data and generate any special offers so that you can put it onto their receipt.

And that's not even starting to get into all the other less-customer-synchronous stuff that you still need CPU power somewhere to do. Managing stock levels, orders, deliveries, price changes, anti-"shrinkage", employee shifts, market-research, status and repairs of freezer-units, operational logging and telemetry, every form of reporting/dashboard "strategic insight" stuff beloved by upper management...