We do focus on the detail aspects of the TWS API in this group and application level topics are generally out of scope. But I am sure there are current and future group members that need a little help along the lines of your question.
You should start with the if you have not done so yet. Work through it from to to bottom so that you get a feel for all aspects. It is fine to jump over sections that are not immediately relevant to you.
Since you are familiar with Java, take a look at the source of the ApiController class in the com.ib.controller package. It is a good example of how you can hide a lot of the necessary API details and idiosyncrasies (such as request IDs) from your application logic. It should help you create an interface to TWS API that works for your application architecture. And there is nothing wrong with a multi-threaded WebApp mindset consisting of services and controllers.
The TWS API is inherently asynchronous and as such a great fit for a micro-service/multi-threaded/reactive application stack (in any language, not just Java). We hide TWS API details behind Java CompletableFutures, Java Flows, and Java Streams, and all of our applications do use several to many threads for executing real time and order processing tasks.
´³¨¹°ù²µ±ð²Ô
