Concurrency in Java – I came up with a design I feel comfortable with

I think this is crazy, coz now you have HTTP stuff leaking into your source code. It&#x27;s just clearly a different abstraction, a worse mess that implementing Callable .<p>You can implement Callable in a lambda now, so a wrapper can be conjured up easily when you need it. <a href="https:&#x2F;&#x2F;www.concretepage.com&#x2F;java&#x2F;jdk-8&#x2F;java-8-runnable-and-callable-lambda-example-with-argument" rel="nofollow">https:&#x2F;&#x2F;www.concretepage.com&#x2F;java&#x2F;jdk-8&#x2F;java-8-runnable-and-...</a> (I agree implementing Callable in the business logic was naff)

Architectural and personal preferences aside, consider what you had to put in to compensate for the stuff you took out.<p>Payload serialisation and deserialization.<p>An http client<p>An http server<p>Not only this has nothing to do with the domain of the problem you are solving, it is very likely be less performant then direct in-memory method calls.

I had somehow not understood that you ran the api yourself. So at first it seemed reasonable to use the HttpClient to fetch someting that was available over HTTP somewhere. But then I realized that you hosted the api yourself. To me it seems very inefficient to introduce both server and client to analyze some text.

Just use parallel streams?<p>This makes absolutely no sense.

I prefer some extensions to Netty EventLoop and EventLoopGroup classes. You get very clear semantics on the pool of threads you create. Running additional calls in async manner lets you add tasks back to the same thread in an orderable way. They implement ExecutorService so existing code won’t be impacted. As far as Runnable semantics, use CompletableFuture or lambda enclosures and very little of the reuse issues appear.

If your tasks are CPU-bound, and you are ready to move outside your process, why not consider your deployment options? If you are deploying on AWS, AWS Lambdas were invented for exactly this kind of processing.

At this moment, you might just use NodeJS with multi running instances to achieve the async+concurrency natively

And I&#x27;d be happy to get your feedback on how to improve on it.

Perfect way to shoot yourself in the foot

I prefer Guava&#x27;s ListenableFuture for java concurrency. No reason to use http or json for in-process work.

Now we have N+1 problems or how to microservice at microscale. The article really misses a &quot;must have&quot; these days piece - Kubernetes service deployment yaml for the server side task.