"""This seems horrible design to me. """<p>Have you actually read the code? I just did and there is barely any thread-related code in the example. It's mostly code to push and pop stuff from a queue.<p>Personally I would turn this into a little Java/AWS framework whose API is based on a high level queue object to abstract away the communication with SQS. Probably simply modelled after a java.util.concurrent.BlockingQueue and configurable through Spring so that it becomes a nice reusable component.<p>Then it gets totally simple and interacting with those (remote) queues will not be any different than with one kept in memory for example. Since it is all thread safe it will be a no-brainer to create a simple workflow where you take stuff from one queue and put it in another.<p>I seriously don't understand why people are so afraid of threads. All you need is a good and well tested abstraction for common patterns.<p><a href="http://www.javaconcurrencyinpractice.com" rel="nofollow">http://www.javaconcurrencyinpractice.com</a> is probably a good start for Java people with the threads-are-evil mindset.<p>S.
"The architecture uses two thread pools: one to run queries and one to get record values. Applications must carefully tune the number of threads in each pool so the queries to overwhelm the gets. Using a query thread pool with 2 threads and a get thread pool with 32 threads it was possible to perform 300 TPS on a small EC2 instances. "<p>This seems horrible design to me. Surely it must be possible to make it asynchronous and event driven - getting rid of the need for threads?