Curriculum·G901 Market Data and Its Failure Modes·about 34 min
When the feed goes dark
By the end of this lesson you can
- →Explain that a market's data and trading can stop entirely, not just slow down
- →Describe how a hardware fault and a failover that did not trigger halted the Tokyo Stock Exchange for a day
- →Reason that a failover only protects you if it actually works when the primary fails
- →Design a system with a safe plan for its feed or venue going completely dark
Graduate · enrolled learners
This lesson opens with The Tokyo Stock Exchange outage, 1 October 2020.
- What happened
- A piece of hardware in the Tokyo Stock Exchange's trading system failed, and the system was supposed to switch automatically to a backup, but because of a configuration setting the automatic failover did not trigger, so the fault was not caught and contained. With no working failover, the exchange could not distribute market data or accept orders, and it halted trading across the entire market for the whole day, the first full-day outage in its history, freezing the world's third-largest stock market. No money was stolen and no strategy was exploited; a single hardware fault, plus a backup that did not take over, took an entire market's data and trading to zero, and the exchange's president later resigned. The lesson is not that hardware failed, which hardware does, but that the safeguard meant to handle the failure, the failover, did not work, so a routine component fault became a total outage. A system depending on that market had, that day, no data and no venue at all.
- The decision point
- A market's data feed and trading do not only slow down or degrade; they can stop completely, going to zero for hours or a day, and when they do, every system depending on that market has, in that moment, no data and no venue at all. The Tokyo Stock Exchange outage is the case: a hardware fault whose automatic failover did not trigger halted the entire exchange for a full day, because the safeguard meant to catch the failure failed too. This extends the course's data-feed lessons to their limit: a feed can be up, a feed can lie, and a feed can go completely dark, and the last case is not hypothetical for even the largest, most robust venues. The deeper point is about the failover: a backup only protects you if it actually takes over when the primary fails, and a failover that is misconfigured, untested, or silently broken is not protection, it is the appearance of protection, which is worse because it is relied upon. So the discipline is to assume that any feed or venue a system depends on can go fully dark, to have a defined safe behavior for that case, halting new risk, protecting open positions where possible, and not blindly resuming when the feed returns, and to treat every failover and backup as something that must be tested under real failure rather than trusted because it exists. The Tokyo Stock Exchange outage is what a dark feed looks like at the scale of a national market, and its real teaching is that the plan for the feed going dark, including the failover, is only real if it has been proven to work when the primary actually fails.
What you will be able to answer
- →Why did the Tokyo Stock Exchange halt for a full day (Oct 2020)?
- →What does the Tokyo outage show about data and trading?
- →What does a failover actually protect you from?
- →How to design against a feed or venue going dark
Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.
It is free. We do not sell the list and there is nothing to buy at the end of it.
Sources and review
Confidence high·Volatility low·Reviewed 2026-09-18·Owner unassigned
Contested
The loss is recorded as 0 because the outage halted trading rather than causing a theft or a direct market loss; the economic disruption of a national market closed for a day is real but not a single figure. The lesson uses the dark-feed and failed-failover mechanism.
The exact technical cause is described in the exchange's own review as a hardware fault combined with a failover that did not switch over as intended; this lesson summarizes it as a failover that did not trigger, which is the transferable point.
