In most competitive FPS, the server will always have the final authority upon hit. What you’re trying to do on the client is to make the best possible prediction on what the hit will look like.
So, if we take your example:
- Client fires the shot
- Bullet is spawned on the client and is multicast to the other players
- The server will be the final authority on whether the bullet has been a hit and will map the location of the hit.
- In the meantime, the client will predict and correct as needed the location of the bullet as it receives the information from the server.
If there’s latency on an FPS, you might think you hit a player, but you actually didn’t, because the server has the current position of the player, while you are still set on their previous location.
A lot of time has been spent trying to find the best way to solve that problem on modern FPS. And so far the best solution has been to make client-side predictions and latency compensation because, at the end of the day, you need to rely on the server to validate the hit if you want your game to be competitive.
Valve made an excellent article on the topic. You should check it out: Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization - Valve Developer Community
If you want to reduce latency for your players, just not manage its effects on the player experience, there’s a new type of server provider that is focused on that. Edgegap, for example, will spawn a game server where your players are, instantly and on-demand.