Hook: Today’s Habr digest featured an article titled "Computers in the National Economy: Railways, Aeroflot’s ‘Sirena,’ Agriculture, and Construction." I got hooked because behind the mundane image of "Aunt Valya at the window tapping away at a strange terminal" lies an engineering story that’s barely dissected in computer science textbooks. Sirena was the USSR’s first real-time online mass service system with a geographically distributed terminal network, launched on April 21, 1972. And it solved the same problem as the American SABRE (American Airlines + IBM) — automating airline ticket reservations. Both systems emerged around the same time. Both operated in the era of ferrite memory and drum storage. But they took fundamentally different paths: SABRE — toward the mainframe and a global GDS empire, Sirena — toward a distributed network of regional data centers and its own operating system. And then the Soviet version hit the same wall as all Soviet IT: not hardware, but institutional inflexibility and the inability to sustain an open-source-like ecosystem.
Central computing complex — two specialized M-3000 systems (developed by NIIUVM, mass-produced by the Kiev VUM plant), connected via switched or dedicated telephone lines to Aeroflot cashiers’ subscriber terminals and regional information processing centers based on M-6000/M-7000 systems. Chief designer — Academician Vladimir Alexandrovich Zhozhikashvili (1925–2008), head of Laboratory No. 17 "Automated Mass Service Systems" at the Institute of Control Problems of the USSR Academy of Sciences (now IPU RAS). Development began in the mid-1960s.
SABRE (Semi-Automated Business Research Environment) — a joint project between American Airlines and IBM, initiated by American Airlines CEO C. R. Smith in 1953. By 1960, the architecture was finalized, and in 1964, the system was commissioned on the IBM 7090, later migrated to the IBM System/360.
| Parameter | SABRE (USA, 1964) | "Sirena-1" (USSR, 1972) |
|---|---|---|
| Launch Year | 1964 | 1972 (8-year delay) |
| Hardware Base | IBM 7090 → System/360 | M-3000 (IBM/360 architecture clone) |
| Central Machine Memory | Hundreds of KB → single-digit MB (S/360) | 256 KB |
| Channel Speeds | Up to 2400 bits/s | 300–2400 bits/s |
| Coverage | All American Airlines ticket offices in the USA | ~400 cities in the USSR |
| Throughput | Thousands of transactions/day (SABRE’s peak — 7600 bookings/day by 1964) | 2 requests/sec = ~7000/hour peak |
| OS | IBM’s proprietary development | Proprietary OS TAIS (only in "Sirena-2") |
| DBMS | Proprietary, later transition to System/360 + DB | DBMS SAK |
| Protocol | IBM proprietary | UDP analog — "unreliable datagram delivery, ~97% reliability" |
| Architectural Pattern | Centralized mainframe + terminals | Distributed-hierarchical network of regional data centers |
The most astonishing part: The M-3000 was a software-compatible clone of the IBM/360, developed by NIIUVM. That is, the Soviet machine stood on the same architectural rails as SABRE. And it implemented the same functionality — real-time online booking. But 8 years later and in a country ten times larger, with a geographically distributed network (not a single mega-mainframe in Briarcliff Manor, New York).
When SABRE launched in 1964, it had one central mainframe in Briarcliff Manor and terminals in major U.S. cities. The connection — dedicated lines. All logic — in one box.
"Sirena-1" took a different path: a central complex in Moscow + regional data centers on M-6000/M-7000, with which terminal cashiers communicated over 300–2400 bits/s telephone lines. This was a distributed-hierarchical architecture — data from terminals was routed to regional centers, and regional centers exchanged information among themselves. Technically, the ability to access any regional data center from any terminal was implemented, though in practice, this mechanism was limited. And this was 20 years before TCP/IP and 15 years before SABRE evolved into a distributed network via the SNA protocol.
"Sirena-2" (from 1982) operated on a datagram delivery protocol with no delivery guarantees, functionally analogous to UDP — 8 years before RFC 768. Developers claimed ~97% message delivery reliability from terminal to data processing center. This means Soviet engineers independently arrived at the same architectural idea as the Western creators of UDP (David Reed, 1980): for real-time transaction systems, fast "unreliable" delivery with application-level confirmation is better than a slow guaranteed channel. The difference was that David Reed wrote the RFC in Palo Alto at a Xerox PARC desk, while the "Sirena-2" developers validated their idea through Aeroflot ticket offices in Magadan and Vorkuta.
During the creation of "Sirena," the idea of conducting dialogue using so-called dialogue cards was first formulated: each request created a record on an external medium containing all the variable parts of the dialogue. This was effectively a message log in the sense it’s used today in event-sourcing architectures. The idea was dictated by simple engineering necessity: 64–256 KB of RAM couldn’t store the entire session context, so the context was offloaded to disk as a "card" with the variable part of the dialogue. Thus, hardware limitations gave birth to an architectural pattern that outlived the system by 30+ years and is now called event sourcing or CQRS.
By the early 1980s, Soviet engineers realized that competing with international GDS (Sabre, Galileo, Amadeus) required abandoning their own architecture. "Sirena-3" conceptually discarded all old developments:
Several parallel narratives, all about institutional, not engineering barriers:
Airlines refused to enforce the TCF order, deeming it gross interference by the ministry in their affairs. The decision to collect the fee was left to airline management — meaning state will ended where the subordinate vertical began.
State funding for "Sirena-3" was halted (the exact reason isn’t stated in open sources, but the context is the general crisis of the Soviet economy in the second half of the 80s), preventing the full implementation of the alternative "Sirena-Sirius" project, which the "Sirena-2" developers prepared in opposition to a complete system replacement. By the early 1990s, both projects coexisted in parallel, neither completed.
The USSR’s collapse in 1991 organizationally tore apart the once all-Union system into separate republics and economic entities. Development teams split into competing enterprises: ZAO "TAIS" (from "Sirena-2," later TAIS PSS) and ZAO "Komtekh-N" (from "Sirena-2M"). In 1992–1994, they ported the system to IBM PCs in parallel: TAIS via SM-2 emulators, Komtekh-N natively. Two systems competed.
"Sirena-3" formally survived until the late 90s and was discontinued as "quite suitable for a unified USSR with a command economy, but too costly for individual airlines."
During the same period, SABRE evolved into a global GDS:
Sirena didn’t follow this trajectory. Not because the engineers were worse — Zhozhikashvili and his team in 1972 built a system functionally equivalent to SABRE. But because evolving into a global GDS requires an institutional environment: IPOs, shareholders, competition for margins, a global market, open standards. The Soviet system had technical evolution without institutional evolution. And in post-Soviet Russia — institutional freedom, but a devastated technical base and 10 years of lost time.
After all transformations, TAIS PSS (the successor to "Sirena-2") still operates today — serving Russian airlines and agencies. According to Wikipedia (as of 2025), in Russia and some former Soviet republics, the following are active:
The irony: A system born in 1972 with 256 KB of memory and 300 bits/s telephone lines is still alive in 2026. Its users — airport cashiers and ticket agents — likely don’t even know they’re working with logic that’s a contemporary of Apollo 17. In this sense, "Sirena" is the Soviet equivalent of COBOL: engineering-conservative but institutionally unkillable, outliving everyone who tried to replace it.
In 2008, the monograph "Vertlib V.A., Bilik R.V., Farkhadov M.P., Petukhova N.V., Myasoedova Z.P. — ASMO for Managing Seat Allocation in Air Transport — 'Sirena': History of Creation and Development" (MAKS Press, 73 pp.) was published — essentially the system’s official chronicle, written by its living creators.
There’s a non-obvious layer here that truly hooked me. Look at "Sirena’s" evolution:
This is the exact pattern of what the modern IT industry calls the legacy trap — or, more gently, architecture tax. A system born under strict constraints (256 KB, telephone lines, no IBM) created its own optimal stack for those constraints. When the constraints lifted, the architecture didn’t automatically adapt. It took 14 years (1986–2000) and the collapse of the original infrastructure (the USSR) to discard the stack. And even then, not completely: TAIS PSS in 2026 is a hybrid of proprietary logic and standard protocols, where both eras live on.
And here’s the main takeaway I arrived at: "Sirena" isn’t about backwardness or heroism. It’s about a universal law of complex systems: the first successful architecture becomes a prison for future generations. SABRE was lucky — it had IBM, which in the 1970s opened System/360 to external integrators, giving the ecosystem an evolutionary path. Sirena had no such path: the Soviet planned economy didn’t know how to create "open standards with royalty-free licenses." The stack was either secret or defense-related. There was no middle ground.
"Sirena-1" launched 8 years after SABRE but with a more complex architecture. SABRE in 1964 was one mainframe + terminals. "Sirena-1" in 1972 was a mainframe + regional data centers + terminals in 400 cities + routing protocol between data centers. That is, Soviet engineers immediately went for a more complex topology because you couldn’t serve 400 cities via telephone lines through one center in Moscow — the lines would choke.
The 1957 "Automaton Driver." From the same Habr article: in 1957, the USSR built an "automaton driver" — a system capable of operating an electric train without human intervention, the same year Sputnik launched. Essentially, this was the analog of today’s metro autopilot — with a route profile in memory, track sensors, and correction via waypoints. The engineering culture was at a high level. The problem wasn’t "we can’t," but "we can’t turn it into an industry."
Zhozhikashvili built his career not on "Sirena," but on queuing theory. Before "Sirena," he worked on contactless telemechanics systems using magnetic elements with rectangular hysteresis loops (essentially, precursors to ferrite memory). After "Sirena," he moved into speech recognition (founded a lab for computer speech recognition at IPU RAS, lived to see publications in 2009). That is, his entire life was one long search for the answer to "how does a machine understand humans": first through hardware, then through mass service networks, then through voice. "Sirena" was the midpoint of this journey, not its peak.
In 1972, a 300 bits/s channel meant 30 bytes per second. To transmit 500 flights with fares, you needed ~50 KB = ~1700 seconds = 28 minutes just for data transfer. This means that in "Sirena," flight data was stored locally in each regional data center, and the central complex synchronized only deltas. That is, engineers invented delta-sync before the era of cloud CRDTs — purely out of necessity to save bits on copper wires.
Severodonetsk NPO "Impuls" was the Soviet analog of IBM’s Hardware Division. The city of Severodonetsk (Luhansk region), the VUM plant (Computing Control Machines) — there they mass-produced the M-2000, M-3000, M-4030, M-6000, M-7000. One city in the steppe supplied the entire country with a line of automated process control systems — from "Sirena" to nuclear power units. In 2014, Severodonetsk found itself in a war zone. Now it’s under Russian control, the plant is destroyed or repurposed. The line of Soviet computer engineering has been physically eradicated.
What I truly appreciate here:
"Sirena" is a rare case where engineering superiority and institutional catastrophe coexist in one object. A system in which:
proved powerless against the Soviet institutional machine, which couldn’t turn its own breakthroughs into a globally competitive product. And in this, frankly, there’s something very familiar — any innovation born in a closed ecosystem is doomed to stagnate, even if technically it’s 10 years ahead of the world.
SABRE today is a $4.5 billion market cap, billions of transactions, a global GDS. "Sirena" today is TAIS PSS, serving the Russian market, a niche product remembered only by cashiers and IPU RAS engineers. Both systems started from nearly the same point in the early 70s. Fifty years later, one built an industry, the other merely survived.
And the moral, as always, is engineering: technical perfection without an ecosystem is a brilliant prototype in a museum. Technical imperfection with an ecosystem is billions in market cap. SABRE wasn’t technically better than "Sirena." But around it was IBM, NASDAQ, competition, shareholders, patent wars, open interfaces for travel agents. Around "Sirena" was Gosplan, TCF, the Ministry of Transport, and one academician who, until his last days, tried to drag the system into the era of open standards.
And one more thought that won’t let go: "Sirena" is the version of the Russian IT industry we didn’t inherit. The version where we had our own operating systems (TAIS), our own DBMS (SAK), our own protocols (UDP analog), our own engineering school (IPU RAS, Severodonetsk NPO "Impuls," Kiev VUM). All of it is destroyed — physically, institutionally, politically. Instead, we now have leasing Western clouds, Postgres forks, and import substitution through rebranding. Maybe the most important thing "Sirena" can remind us of is we once knew how to build complex systems from scratch, from ferrite rings and copper wires. The question isn’t whether we can do it now. The question is whether today’s institutional environment will let us do it again.
Sources: