-
When Two Kings Claim the Throne: Consistency in Distributed Systems
Truth becomes complicated when the kingdom keeps more than one copy of it. When One Truth Becomes Many: Distributed Systems The Kingdom Keeps Copies for a Reason: Distributed Data and Replication In a small application, truth appears simple. A user changes an email address, the application saves it, and the next request retrieves the same value. One database, one authoritative record, and usually one short path between the person making the change and the system storing it. Distributed systems complicate that arrangement. Data may be copied across regions, databases, caches, queues, search indexes, and services. Replication improves availability and performance, but it also creates a difficult question: when several systems…
-
Messenger Ravens and Royal Couriers: Building with Messages and Events
Not every message requires the messenger to wait at the castle gate. A traveler arrives at the castle gate with an urgent request. The guard carries it to the steward, the steward consults the royal records, and the traveler remains outside until someone returns with an answer. This arrangement works when the traveler needs an immediate response, and the castle can provide one quickly. It becomes fragile when the work takes several minutes, the responsible official is unavailable, or five hundred travelers arrive at once. The problem is not that the road is poorly built. The problem is that every participant must remain available throughout the conversation. In the previous…
-
Roads Through the Sky: Connecting Cloud-Native Services
A distributed kingdom survives only when its distant cities know how to speak. A single castle can rely on hallways. The kitchen knows where the pantry is, guards can walk directly to the armory, and a steward who needs an answer can cross the courtyard and ask for it. Once the kingdom spreads across distant cities, those assumptions disappear. The treasury may live in one region, the guild registry in another, and the market serving the public somewhere else entirely. Each city can function perfectly on its own and still leave the kingdom paralyzed if the roads between them are unreliable or poorly governed. Cloud-native systems inherit the same problem.…
-
The Castle That Appears on Command: Serverless Architecture
Sometimes the finest fortress is the one that exists only when it is needed. A Fortress Without a Permanent Gate: What Serverless Actually Changes For most of software history, deploying an application meant giving it somewhere permanent to live. A server was provisioned, a runtime installed, and a process waited for requests whether anyone arrived or not. Virtual machines changed how servers were acquired, and containers changed how applications were packaged, but the assumption remained: something was running, and engineers were responsible for keeping it alive. Serverless challenges that assumption by asking whether the fortress needs to exist when nobody is visiting. The name is misleading because servers still exist.…
