Let's make some back-of-the envelope calculations:
You have 2000 devices. If you're using 5 GHz WiFi, you'll have around 45 available non-overlapping channels for the US, a bit less in the EU, if you're using just 20 MHz per channel. This is of course, assuming you have equipment which properly supports dynamic frequency selection, and this might be an issue (or it was 4-5 years ago, when I looked into it at least!).
Now, if we try to put a reasonable number of devices per access point, this would give us around 10 devices per AP (this number can be adjusted a bit if more precise calculations are to be done). So you'll need to fit 200 access points into 45 channels. I've seen the following formula for the number of hexagonal sectors in a cluster: \$N=a+ab+b\$ So you'd need to pick a and b such that the N is closest as possible to the number of allowed channels in your region. I think that the derivation was explained in Wireless Communications from Theodore Rappaport. This book will also have some calculations about peak and average utilization of a network system, so you could get some estimates on how much throughput you actually need, when we take into account average number of requests per minute per AP.
This all should be doable, with say 5 to 6 clusters, but you'll probably need to use highly-directional sector antennas pointing downward from the roof and a very low transmit power, so not to disturb co-channel stations in neighboring clusters.
Then there's also the part which I don't remember so well and that's how feasible this is to do with actual WiFi network protocols as well. My feeling is that 200 ms update rate is a bit high. Perhaps it might be worth it to try to have the system work reliably with some missed updates, just in case.
Furthermore, there are certain wait periods defined in the standards themselves which are going to affect your operation. I don't remember actual values right now, but look up SIFS, PIFS, DIFS, EIFS, AIFS and how they interact. Next, you commented about relaxing the 1 KiB requirement. I personally don't find that all that reasonable. In fact, I'd recommend to go even higher than 1 KiB packet. Namely, with each datagram you send, you'll have extra overhead before it reaches the frame level and goes out into the æther. I don't remember exact values now, but keeping your useful data to the size of around 1.3 KiB is relatively good. The maximum frame size for WiFi is a bit higher than 2 KiB, but for Ethernet, it's around 1.5 KiB (yes, there are jumbo-frames that go up to around 9 KiB, but using them is asking for problems, unless you can 100% guarantee that every single device in the net will support them). If your datagrams are around 1.3 KiB, you'll have more than enough space for WiFi and still be able to fit the frame into the Ethernet. For these type of calculations, I found books from Matthew S. Gast very useful. He wrote 802.11 Wireless Networks, 802.11n: A Survival Guide and 802.11ac: A Survival Guide, which form a series.
Also as an advice, be sure to do the calculations, select which network standard you want to use and enable ONLY that single standard and disable backward-compatibility. The issue is the so-called "air time". Basically, if you have backward compatibility enabled, some of the service data will be sent at the rate at which even the oldest compatible device will be able to receive it. It happened to me that once a WiFi network downgraded down to IEEE 802.11 with no letters speed! The result is that at low speeds, even small maintenance packets needed to keep the network alive will take long time to transmit.
Backward compatibility was mandated in standards until recently (I don't remember if 802.11n or 802.11ac is the one who broke that), but equipment which allows breaking of that requirement does exist and can be commonly found.
Next, don't forget that for something like this, you'll need serious wired network infrastructure to support all of what you want. I don't go too much into that here, but I'll just say that the wired part can be as complex as the WiFi, if you want it to run properly. Also you mention "the server". For this to work, you'll probably need several physical servers running a single virtual machine redundantly. Even this part will be very complicated.
