You definitely want to use UDP. For the game, you do not care if the sprite position is incorrect for a short time. Thus, UDP is ideal in this case.
Also, if you have any control over the server code, I would not use separate threads for clients. Topics are useful if you need to make calls in libraries that you don’t have and that can be blocked (for example, because they touch a file or try to make additional network communications). But they are expensive. They consume a lot of resources and, as such, actually make things slower than they can be.
So, for a network game server where latency and performance are absolutely important, I would just use a single thread to process a queue of commands that have state, and then make sure you never perform an operation that blocks. Therefore, each command is processed in order, the state is evaluated and updated (for example, a laser explosion intersects with another object). If a command requires a lock (for example, reading from a file), you need to perform a non-blocking read and set the state of this command accordingly, so that your shell will never block. The key is that the shell can never be blocked. It just starts in a loop, but you will need to call Thread.sleep (x) accordingly so as not to waste CPU.
As for the client side, when the client sends a command (for example, they started the laser or some of them), the client would create a response object and insert it into the card with the sequence identifier as the key. Then it will send a request with a sequence identifier, and when the server responds to this identifier, you simply look at the response object on the map and decode the response to this object. This means that you can perform parallel operations.