Trading Network? In combination with "I am far from knowledgeable"?
Run. Don't turn around, don't look back! RUN! Until you find someone who can help you with this. I don't think NESE, although there's networking gods walking around here, is a place do discuss such a project.
That may sound overly dramatic, but without precisely defined requirements, and to the point definitions how and how far to fulfill each of them, all your engineering effort will remain foggy.
Fingerpointing between business and IT will ensue, once things go wrong, and trading departments are VERY quick with their fingers, and they usually have very good ties to top management. I strongly suggest you pursue a thorough top-down approach here to avoid disaster.
That being said, here's a few things to consider:
- 99.99% is a big number. That probably will require involving facility management people to provide A/B wiring closets (half of the trader workstations on A, half on B), A/B power supply for the trading floor, wiring closets, data centers; path redundancy for inter switch FO cabling etc.
- be absolutely sure that someone in the project understands in depth
how trader workstations, trading gateways, 3rd party connectivity to
(stock/financial) exchanges actually interact in terms of data flows.
Multicast is bound to appear somewhere in this, and it alone can come in different flavours.
- consider segregating (in extenso: seperated network hardware, servers, workstations) really critical data flows from general purpose things like office IT, casual internet access and mail transport. For that, the project first needs to understand the data flows involved, of course. One solution for a trader could be: run trading applications on the workstation, use Office IT via some form of virtual desktop (or vice-versa, if trading workload is suitable for virtual desktop).
- make sure that you have a monitoring/reporting platform that can measure latency, network load, availability, not only on networking gear, but also including servers and workstations; even transaction times as observed by the clients, trading gateways and servers. Make sure that it does measure and report the criteria the project was given. Else, IT will have no way to baseline nor to defend against "the network is slow!" from business departments.
Disclosure: from 2002 to 2009, I've been working as a network engineer for the Swiss Stock Exchange (then known as SWX, later as SIX Swiss Exchange). We did not have a trading floor as such, but we ran the "other end" of a trading platform (the server side) and our own market surveillance departments had similar requirements of uptime, reliability and low-latency.