There is no general solution to this problem. Your solution will be specific to your situation, and unusable for many other users, and vice versa. All with their own varying tradeoffs.
For example, some hosting companies spin up new instances with the new update, that then replace the old instances, but this is not possible on many hosts. This also glosses over the fact that what that sentence means can vary wildly depending on the technologies used. For example, a new AWS instance is very different from replacing a container. It’s also not going to work for people on shared hosts.
To find a truly concrete answer you will need to work with your host. If their deployment process is not atomic then that’s an issue with that host that you need to work with or work around. How you do that is unique to your host and technology stack. The solution for AWS environments for example only works on AWS.
Or you may choose to rely on a cache based system, which only works for certain kinds of sites, and requires additional hardware and software. This might work great for a newspaper for example, but it won’t work for a membership site, and has other tradeoffs too.
And for some hosts, usually shared hosts accessed directly, it simply cannot be done as there is no way to bulk update files in one single atomic step. The best they can hope for is a maintenance mode or holding page.
Either way, it’s highly dependent on your hosting platform, tech stack, budget, the type of site you have, and commercial needs. If you constrain this question down to your specific tech stack, there may be a canonical solution, but it would only apply to users in your specific use case. E.g., there is definitely solutions for AWS/EC2, but it only applies to that particular technology stack.