- Caches/Databases that should keep as much stuff in memory as possible (i.e. if you have a 32gb es instance you actually gain a lot from "fast memory")
- In-Memory Databases
- In-Memory RPC/message broker which of course has as a limitation factor the memory bandwidth.
In all cases the memory bandwidth might be a important factor.
For all the cases you mention, the critical factor is the product of the average transaction size and the transaction count per second. As long as this value is smaller than the RAM bandwidth, the application will not be RAM bandwidth-bound.
Generally speaking, databases are kept in memory to minimize latency, not maximize throughput. Bandwidth is not really a problem. Having to update 10 GB/s of a database would be highly unusual. Having to get data from random positions in a disk or SSD is much more common.
As for the message broken, it's not clear to me why the bandwidth would "of course" be the limiting factor.
There are many more:
- Caches/Databases that should keep as much stuff in memory as possible (i.e. if you have a 32gb es instance you actually gain a lot from "fast memory")
- In-Memory Databases
- In-Memory RPC/message broker which of course has as a limitation factor the memory bandwidth.
In all cases the memory bandwidth might be a important factor.