Good questions! There are a number of aspects regarding throughput:
- How many update calls can IC handle per second.
Short answer: unlimited. This is because IC is able to throw in more resources and scale out by adding subnets.
- How many update calls can a subnet handle per second.
Short answer: it depends. Because all machines participating the same subnet will be running identical computation, the theoretical limit is bounded by hardware (CPU, disk) and network. It also depends on what these update calls actually do, you can imagine some calls consumes more cycles than others.
So really I’d ask a slightly different question: “how many cycles can a subnet consume per second”, if we use cycles as an approximation of unit computation. This will not be too different than traditional platforms offering VM or container solutions.
Besides CPU and disk bound, there is also a network bound. Essentially all blockchains arrange inputs into batches (blocks), and process them one by one. So network bandwidth dictates how many messages can be included for processing per second. An ideal situation is to be able to saturate both available network bandwidth and available hardware capacity. But of course in reality there are always overheads that cannot be avoided.
- How many update calls can a canister handle per second.
Because each canister handles each update calls one by one, this implies there is a limit to the throughput per canister. Again, each call is different, so the best way to think about it is still in terms of “cycles”. A very rough estimation is how many cycles can a single execution thread (e.g. one CPU core) consume per second.
Back to your original question. If 1000 calls are sent to different canisters (on the same or different subnets), then all of them will be processed in parallel. If 1000 calls are sent to the same canister on the same subnet, then all of them will be processed in order. It really depends on how many cycles each call will take. If each call take 1s, then the 1000th will only be completed after 1000s.
You also asked about persistence. We only persist states periodically (say after each batch), so the overhead of disk I/O is not per message.