3 ms·
Are you assuming that 1 order is one inbound request, one database transaction, and one outbound response? Because it isn't that. You need to integrate with add
by onion2k 3y ago
Are you assuming that 1 order is one inbound request, one database transaction, and one outbound response? Because it isn't that. You need to integrate with address verification services, fraud detection, payment services, stock management, communications like email and alerting, telemetry, and more. It's all manageable and a lot of it can be queued, but it's still hard.
- ndriscoll 3y agoI'm not, otherwise something like 0.1% would be a reasonable upper bound. Even if you figure each order involves 20 async steps, that would be ~8k steps per second, which is nothing for a modern server. My old i5 can do 70k simple requests/second (the first type you describe) on the JVM with the app and database on the same computer (so contending for CPU time). A modern server CPU is ~15x more capable than mine without getting into multi-socket. Put another way, a dual socket Xeon platinum can give you 120 cores. To do 400 orders/second on such a machine, you need to do less than 300 ms of core-time per order, which is an insanely large number. The things you mentioned spend almost all of their time waiting.