Obsolete Bytes: Ticker Tape - The First Data Streaming Platform

Obsolete Bytes: Ticker Tape - The First Data Streaming Platform

How the stock ticker revolutionized data communication

Published on Monday, January 13, 2025

Since I learned about stock tickers, I’ve been captivated by them. While they may be simple, obsolete devices, I find them intriguing because they were among the first devices to implement many modern concepts we now take for granted in software development for distributed systems.

History of Stock Tickers

Stock Ticker was the first specialized financial communication device. It was a modified telegraph receiver, where the operator typed stock quotes on the sender end, and on the receiver end, the machine would print the quotes on the ticker tape.

There were earlier 'general' telegraphic printing systems, but Edward Calahan's stock ticker was the first specialized device for stocks in 1863. However, true popularity came with Thomas Edison's patented version (Patent US140488A), which could be synchronized so all the tickers would receive the same data at the same time, thus fixing the biggest problem of data synchronization that plagued the original version, where some machines would lose a character and fall behind with the data. With Edison's device, operators could synchronize all the printers by sending a special reset command to all receivers.

women-in-waldorf-astoria.jpg

Stock market board operators at the Waldorf-Astoria Hotel in 1918

Before mass adoption, stock tickers were a novelty item. Sure, there were electric telegraphs (the 1830s), and for more than 20 years, they were mainstream, especially in affluent households and in "fintech." But, still, this was "the magical machine" that printed codes that would make you rich!

stock-cigarettes.png

The print advertisement for "Duke's 'Preferred Stock' Cigarettes" features a woman fascinated with Stock Ticker.

Imagine a world where the tickers were a novelty, where "wired phones" were rare and called just "phones." I miss Bowler hat days.

Stocks were not the only thing that the Ticker Tapes were used. Gold and Oil tickers were also popular, but other highly formatted real-time data, like sports scores, were also sent in the later years.

Ticker Tape Parades

One notable legacy of stock tickers was Ticker Tape Parades, celebrations in urban settings, usually in New York, where large amounts of ticker tapes were thrown.

ticker-tape-parade-ny.jpg

The ticker tape parade in NY in 1959.

"The first ticker-tape parade" was a spontaneous celebration in 1886 during the dedication of the Statue of Liberty.

Hardware Limitations & Protocols

From a modern development viewpoint, we rarely consider hardware advancements, particularly not mechanical moving parts, for computer communication. We operate on a much higher OSI level.

black-tuesday.png

Ticker tape from Black Tuesday (1929-10-29)

Unfortunately, I could not find the exact details for the communication protocol for ticker tapes. The closest thing I did find was the picture of the crash of 1929 ticker tapes.

The best I could conclude about the protocol from this picture was that there were 26 letters, 10 numbers, full stops for letters and numbers, and some special chars for numbers. Letters were printed on the upper line and at the bottom numbers. As far as I can conclude, no special chars mark the "end of a message," like EOT (End of Transmission, Message Terminator, End Delimiter, etc.).

Interestingly, when I was thinking about how to create a solution for the mechanical part of this problem, my first instinct was to rotate the tape by 90 percent and make the message a fixed size so it would always be printed on the exact size. It would be somewhat more practical for the reader, but mechanically, it would be much harder to create. With the actual ticker tape approach, you only have to move the paper from left to right for one side of the char, and that's it! "My approach" would require moving from right to left and up bottom. However, my initial guess is not that far off. Yes, mechanically, it would be more complex, but typewriters in the 19th century had somewhat similar capabilities.

My guess is that the actual protocol used was the same as the telegraphs of that time. Only later, it was upgraded to something more specialized.

Also, Edward Calahan was the inventor of the multiplex telegraph system, which allows two or more messages to be sent simultaneously over the same wire. Interestingly, Thomas Edison had a patent for the Quadruplex telegraph. I'm sure that protocols for stock tickers were advanced and probably used multiplex, even in the 19th century.

modern-stock-ticker.png

High Speed 900 Series Ticker

The Tickers were used even in the 70s. Those were awe-inspiring machines with 900 characters per minute! That's 15 chars per second, more than fifteen times faster than the original, one hundred years ago!

Stock Tickers as Distributed System

Our modern definitions make it easy to define which early patterns of distributed computing Stock Ticker Tapes had. However, we have to consider that they were just trying to find the solution for their specific problems, not define computer networks.

Single Source of Truth

Stock Ticker Tapes had a centralized source of truth. Even if some of the data was not received directly from the source of truth, they received data from repetitors.

Data Streaming

Although it was manual, stock tickers had continuous data flow.

Publisher Sucriber model

Stock Tickers used a simple publisher-subscriber model with a single publisher and multiple subscribers who received the same data.

No Persistence or replay

Stock Tickers did not have memory. Humans were the operation and "memory" part. This was a feature, not a bug, in the case of errors and edge cases. Humans can much more easily adjust to unforeseen problems.

Interestingly, most stream processing and message brokers today do not have replay and (semi) permanent storage capabilities either. I don't like that. Kafka is one of the rare exceptions that can actually store and replay messages indefinitely.

Near real-time

The tickers operated in near real-time. What the sender sent, the receiver received (almost) immediately.

Errors

In addition to obvious human errors, there were also errors at the machine level. They were mechanical devices, but there could also be errors with transmission because the data was sent as a sequence of pulses, as a discrete on/off signal over the telegraph line. A pulse advanced the machine's type wheel in one position. It would be enough to skip just one pulse or have a false positive pulse, not just to break the current symbol, but everyone after until we reset the machine to zero position. If a ticker got out of sync, it would need to be stopped until the next sync signal or to print out jibberish.

Again, this is a (semi)educated guess.

Synchronous

Communication over tickers was synchronous and near real-time.

Asynchronous Stock Ticker in the 19th Century?

Interesting question: Could we have made an asynchronous system with 19th-century technology?

I think we could have made a mechanical device that could "store" the last n characters and replay them on the "second" line after n+1 characters.

Let's make a thought experiment. The most straightforward process is to put n papers in a circle, each paper holding up to one char. The primary operator then inserts new data and puts the characters in order individually per paper. The second operator reads the paper the primary operator just updated and sends it over the ticker. The third operator reads the following paper before the first operator updates it and sends it over secondary ticker tape.

graph TD subgraph Papers[Circular Paper Arrangement] P1[Paper 1] P2[Paper 2] P3[Paper 3] P4[Paper n] P1 --> P2 P2 --> P3 P3 --> |...| P4 P4 --> P1 end OP1[Primary Operator] OP2[Second Operator] OP3[Third Operator] Data[New Data] --> OP1 OP1 -->|Writes characters| Papers OP2 -->|Reads just updated paper| T1[Primary Ticker Tape] OP3 -->|Reads next paper| T2[Secondary Ticker Tape] %% Show the sequence of operations Papers -->|Current paper| OP1 Papers -->|Just updated paper| OP2 Papers -->|Next paper to be updated| OP3 style OP1 fill:#f9f,stroke:#333 style OP2 fill:#bbf,stroke:#333 style OP3 fill:#bfb,stroke:#333 style Papers fill:#fff,stroke:#333

I'm not a mechanical engineer, but let's say you have a wheel (something like a Daisy wheel) with a possible ~40 position (26 chars + 10 digits + 4 special chars). Typing char would set the position of the first wheel on that specific char position and would initialize sending the coded data over telegram for that wheel and the next one.

Another fun thing we can think about is encoding. I will focus on binary, but it does not have to be. Base6 would work, too. It may be easier to "store" mechanically two 0-5 digits than one 0-39 digit for Base40.

Compression algorithms like Huffman coding are also interesting. This approach takes into account the frequency distribution data. Some characters appear much more frequently than others, so we could use that data to optimize encoding, thus giving the shortcodes to frequent characters. However, the output of this is not humanly readable. If we have a fixed length per char, at least in theory, we could learn to recognize the "pattern," but I don't think it is possible with the "stream" of 0/1s. Of course, this solution is the most complex one, and it would be challenging to implement this mechanically, even today. Not to mention, the algorithm was first published in 1952 by David A. Huffman.

Encoding is essential because we did have ways to store machine-readable data in the 19th century. Wheel/Gear-based storing mechanisms were obvious, but punched tapes and cards were used in some capacity.

How would Dr. Emmett Brown, stuck in 1885, find a solution for Stock Ticker problems?

Conclusions

Stock Tickers emerged not from theoretical computer science (which didn't exist yet) but from practical necessity. Many fundamental patterns in computing arise naturally from the problems they tried to solve, regardless of the era.

I think we underestimate how much we can learn from history and obsolete devices in the modern software context. Adding hardware limitations to the requirement makes you rethink every assumption about development, business processes, and how things should get done.

Most developers today work primarily with high-level abstractions and focus only on business requirements. Let's focus more on the fundamental nature of our technical challenges rather than just reaching for the latest framework or tool. We do not put enough significance to the historical context of how and why we got here.

We can do better!

We should do better!

The solution is not always the new JavaScript framework. Perhaps we should focus again on what makes computers tick.

Resources and References