What the Forge Remembers
The forge did not build blindly. Before laying any stone, it consulted Smriti the scribe, who held a record of every building the forge had ever created: the building's name, the forge's name for it, and the cloud's name for it. When the forge received new blueprints, it compared the blueprints to Smriti's record. What was new, it created. What was changed, it updated. What was in Smriti's record but absent from the blueprints, it destroyed. Without Smriti, the forge could not know what already existed. It would try to create buildings that already stood, or leave orphaned buildings the blueprints had forgotten. Smriti was not a backup. Smriti was the forge's mind.
“The state file is not a record of what you asked for. It is the forge's memory of what it built.”
The Two Scribes Problem
Kalpa and Vidhi both built in the same kingdom. Each kept their own copy of Smriti's record, stored in their workshop. One day, Kalpa added a new granary. His copy of Smriti now recorded the granary. Vidhi did not know — her copy still said no granary existed. Vidhi ran her blueprints. Her copy of Smriti said: "create the granary." The forge tried to create a granary that already existed. The cloud refused. Vidhi's run failed. She did not know why. Kalpa's copy was right. Vidhi's copy was stale. The state had forked. Now both scribes had a different memory of the same kingdom.
“A memory stored in two places will diverge. A single authoritative memory cannot.”
The Remote Archive
The guild moved Smriti from each builder's workshop to a shared archive: a sealed chest in the central treasury. Every forge run began with fetching the latest record from the archive. Every forge run ended with writing the updated record back. Kalpa and Vidhi both ran against the same single record. When Kalpa added the granary, the archive was updated. When Vidhi ran next, she fetched the updated record and saw the granary already existed. She did not try to create it again. The two builders could work on the same kingdom without forking its memory. The archive was the kingdom's one memory.
“Move state to shared storage before the team grows beyond one person.”
Avarodh the Lock
The remote archive solved the stale state problem. But it revealed another: what if Kalpa and Vidhi ran the forge at exactly the same moment? Both would fetch the current record. Both would make changes. Both would try to write back. One write would overwrite the other. The result: a state that reflected only one builder's changes, with the other's changes lost, the kingdom in an unknown half-changed state. Avarodh the lock was placed on the archive chest. When Kalpa began a forge run, Avarodh locked the chest. Vidhi's run would wait. When Kalpa finished and released the lock, Vidhi could proceed. The forge runs were serialized. The memory remained consistent.
“Remote storage solves the stale state problem. Locking solves the concurrent write problem.”
The Record That Was Wrong
One morning, a building was destroyed not by the forge but by a flood — directly, without the forge's knowledge. Smriti's record still showed the building standing. The next time the forge ran, it saw the blueprint said "this building should exist" and Smriti's record said "this building exists" — so it did nothing. But the building was gone. The forge's memory was wrong. The guild had to tell the forge: "Remove this building from Smriti's memory. The building is gone. Accept reality." This was a state operation — not a blueprint change, not a cloud operation, but a surgery on the forge's memory itself. The guild performed it carefully, backed up the record first, and restored the correct state.
“State surgery corrects the forge's memory when reality and memory have diverged.”
The Memory That Cannot Be Lost
The guild kept one more rule: the archive chest was never the only copy. Every day, the treasury made a copy of Smriti's record and stored it in a separate location. If the chest was destroyed, the daily copy could restore the forge's memory to yesterday's state. A week of work might be needed to bring the memory current, but the kingdom would not be rebuilt from scratch. The builders also kept Smriti's record versioned: each run created a new version, and older versions were kept for thirty days. If a run created a bad state, the guild could roll back to the version before the bad run. The memory was resilient because the guild treated it like infrastructure, not like a temporary file.
“State is infrastructure. Back it up, version it, and protect it with the same care as the buildings it describes.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Terraform state (terraform.tfstate) is the mapping between your configuration and real cloud resources. Without it, Terraform cannot know what exists. Remote state backends — Azure Storage, Terraform Cloud — store state in a shared location accessible to all team members. State locking (via Azure Blob lease or Terraform Cloud) prevents concurrent writes that would corrupt state. State operations: terraform state rm removes a resource from state without destroying it; terraform import brings an existing resource under Terraform management; moved blocks handle resource renames without destroying and recreating. Back up state: enable Azure Storage soft-delete and versioning. Never edit state files manually — use terraform state commands. Treat the state backend as production infrastructure.