I am creating an RTS with Unity/C#, and have noticed a problem synchronising build queues. Is there an ideal solution to handle button prediction?

In my game there is basic networking code which works. The problem is that the client clicks a button and sends a request to the server, which makes a decision and then sends that back to the client. This lag time is noticable and frustrating when the player is clicking on a button multiple times to add items to a build queue in real time.

I am aware of prediction being used for things like movement in a client-server environment, and have an idea of how this could be solved, but would like someone with experience to guide me.

I assume the simplest way of handling it is that the client will not wait for the server, and instead will check whether the button can be pressed (and purchase order sent) at their end. This sends a build queue item ID to the server, and the server then will respond with an OK or fail outcome.

This works on the assumption the client's verification will be accurate most of the time, and server will only cancel a build queue item if something catastrophic happens. Since the build queue item logic is separate to the question of whether something is spawned (server determines when this happens) it should be okay. But I am likely not getting this right.

I am creating a RTS with Unity/C#, and have noticed a problem synchronising build queues. Is there an ideal solution to handle button prediction?

I think I may have overengineered the solution... Presently when the client clicks a button, it sends a request to the server. The server validates the request (cost if applicable) and then returns the order to create the build queue item. Consequently, when the client clicks a button there's a noticeable lag.

Is server validation for button presses, like build queues, in a client-server model overkill? What would be the ideal solution?