If you sit in on enough system design meetings, you inevitably witness the exact same debate play out on a repeating loop. It usually starts when a team is breaking down a monolithic backend and trying to figure out how the new microservices should talk to each other.
Someone suggests standard REST. It’s stateless, ubiquitous, and deeply understood.
Then, a more performance-minded engineer interjects: "JSON over HTTP/1.1 is too heavy for internal service-to-service chatter. We need strict contracts and lower latency. Let's use gRPC."
It feels like a hyper-modern debate—the battle-tested standard of the 2010s versus the cutting-edge, high-performance tooling of the 2020s.
But if you zoom out, the illusion of modern innovation shatters. Remote Procedure Call (RPC) isn't new. It was conceptualized in the 1970s and standardized in the 1980s. We aren't inventing a new way for computers to communicate; we are just resurrecting a 50-year-old paradigm, dressing it in Protobufs, and multiplexing it over HTTP/2.
This is the quiet truth of software engineering: Technological progress is not a straight line. It is a spiral.
We rarely invent entirely new architectures. Instead, we revisit the exact same fundamental concepts, just one layer higher on the Z-axis of abstraction.
1. The REST vs. RPC Pendulum
To understand the spiral, look at how we got to REST in the first place.
In the late 90s and early 2000s, RPC implementations (like CORBA, DCOM, and SOAP) were miserable. They were tightly coupled, brittle, and notoriously difficult to debug across different languages. If a developer updated a method signature on a server, clients across the network would immediately fracture.
Roy Fielding’s REST (Representational State Transfer) won the web because it provided the ultimate decoupled escape hatch. Instead of executing remote actions, clients interacted with remote resources using standardized, predictable HTTP verbs. It was beautiful, cacheable, and heavily adopted.
But as we transitioned into the era of distributed microservices, REST hit a wall. When you have 40 internal services pinging each other to fulfill a single user request, the overhead of parsing massive JSON payloads and managing stateless HTTP connections becomes a devastating bottleneck.
So, what did we do? We went right back to RPC.
We realized that for internal, tightly-bound systems, we actually wanted strict coupling. We wanted type safety. We wanted binary serialization. Tools like gRPC and tRPC dominate modern backend discussions not because they are conceptually novel, but because they are the 1980s RPC architecture built with 2020s infrastructure.
2. The Return of the Relational Database
You can see this same spiral evolution in data storage.
If you were building a startup around 2012, you were explicitly told that relational databases were legacy tech. "SQL is dead," the thought leaders said. "Schema-less NoSQL is web-scale." We poured billions of dollars into document stores like MongoDB and wide-column stores like Cassandra, convinced that abandoning the rigid constraints of tables and foreign keys was the only way to achieve horizontal scalability.
Fast forward to today. What is the default, undisputed king of databases? PostgreSQL.
Not only has SQL made a dominant comeback, but the very NoSQL databases that tried to kill it have spent the last five years desperately bolting SQL-like query languages onto their engines.
Why did this happen? Because Edgar F. Codd’s "Relational Model of Data," published in 1970, wasn't just a technological trend. It was based on fundamental relational algebra. The math was always correct. The only problem in the 2010s was that the underlying storage engines struggled to distribute that math across multiple physical servers.
Once engineers figured out how to build distributed, globally consistent relational engines (like Google Spanner or CockroachDB), the need for NoSQL evaporated for 95% of use cases. We went right back to SQL.
3. Mainframes to Edge: The Physics of Compute
Perhaps the most massive spiral is where compute actually happens.
- The 1970s (Centralized): The era of the Mainframe. Massive central computers handled all the logic. Users interacted via "dumb terminals" on their desks that did nothing but render the output.
- The 1990s (Decentralized): The era of the Personal Computer. Moore’s Law made chips cheap. We moved compute away from the center and put it directly on the user's desk.
- The 2010s (Centralized): The era of the Cloud. We realized managing thousands of local machines was a nightmare. So, we moved the compute back to massive centralized data centers (AWS, GCP). Our high-powered laptops essentially became very expensive, glowing dumb terminals for web browsers.
- The 2020s (Decentralized): The era of the Edge. The cloud is now too slow for AI inference and high-performance UX. So, via WebAssembly (Wasm), local-first databases (SQLite in the browser), and edge networking, we are pushing the compute right back down to the user's local machine.
Mainframe to PC. Cloud to Edge. It is the exact same architectural breath, inhaling and exhaling across decades.
Why the Spiral?
Why do we constantly go backwards to move forwards? Is it just a lack of imagination? Are we victims of sunk cost, clinging to the paradigms we learned in university?
No. The spiral exists because software architecture is ultimately bound by physical reality.
We are constantly negotiating between conflicting, immutable constraints: the speed of light (network latency), the cost of silicon (compute power), and the CAP theorem (consistency vs. availability).
When we invent a "new" paradigm, we are usually just optimizing for one of these constraints by willingly sacrificing another. When we moved to NoSQL, we sacrificed consistency for availability. When we moved to the Cloud, we sacrificed latency for centralized management.
Eventually, we push a paradigm to its absolute breaking point. We hit the physical limit of what it can do. And the only way out is to flip the trade-off, looking back into the past for the architecture that optimized for the exact thing we are now starving for.
We aren't failing to innovate. We are just maturing. We are slowly realizing that the engineers of the 1970s weren't primitive; they were dealing with the exact same fundamental laws of computer science that we are. We just happen to have faster Wi-Fi.
Top comments (0)