The Problem of Copy and Forget
The kingdom built the same structure in twelve provinces: a storage house with a guard post and a drainage channel. Each province builder had copied the original blueprint and modified it for their province. When the kingdom discovered that drainage channels needed to be twice as wide — a safety code change — someone had to find all twelve blueprints and update each one. Three province builders had renamed variables. Two had added local modifications. The person doing the update missed one province, updated one incorrectly, and spent three days on work that should have taken an hour. The real problem was not the update. The problem was the copying.
“Copied code creates a debt that must be repaid at every update.”
The Pattern Is Born
Taraka the weaver proposed: instead of copying the blueprint for every province, write the blueprint once as a pattern. The pattern would have inputs — the province name, the capacity, the region — and outputs — the address of the storage house, the ID of the guard post. Each province builder would call the pattern with their specific inputs. Taraka would maintain the pattern in one place. When the drainage channel width changed, Taraka updated the pattern once. Every province that called the pattern received the fix on their next build. The twelve province builders called a name. The name resolved to Taraka's maintained pattern.
“A pattern called by reference propagates every fix automatically to every caller.”
The Registry
Kosha the registry keeper catalogued every pattern the kingdom had created. Patterns were organized by type: storage patterns, network patterns, application patterns. Each pattern had a version. Version 1.2 had the original drainage channel. Version 1.3 had the wider channel. Province builders who called a specific version received exactly that version — no surprises. Province builders who called the latest version received all improvements automatically. Kosha's registry also held patterns published by the forge maker itself and by trusted guilds from other kingdoms. The kingdom's builders did not have to build every pattern themselves. They reused patterns tested by others.
“A registry separates creation from consumption. Creators maintain patterns; consumers call versions.”
The Input and the Output
Prayoga the caller used a storage pattern by providing only what the pattern needed: province_name = "eastern"; capacity = "large"; tier = "standard". The pattern's inner workings were invisible to Prayoga — the specific resource names, the internal networking, the tag schema. The pattern returned outputs: storage_address and guard_post_id. Prayoga used the outputs to connect the storage house to other resources without knowing how it was built. The pattern was an interface: a set of inputs and a set of outputs. The implementation could change without breaking any caller, as long as the inputs and outputs remained consistent.
“A module is an interface. Callers should depend on inputs and outputs, not on internals.”
Bahuta the Multiplier
Bahuta the multiplier needed ten storage houses in the eastern province, each with a different name and capacity, for ten different departments. Without patterns, she would call the pattern ten times with different inputs. With for_each, she passed a map of departments to the pattern: for_each = { accounting = "small", engineering = "large", ... }. The forge called the pattern ten times, once for each department, with the department name and size as inputs. Ten storage houses appeared, correctly named, correctly sized. The calling code was two lines plus the map. The pattern enforced consistency across all ten. When the drainage channel width changed, all ten were updated with one change to the pattern.
“Iteration over a collection of inputs with a consistent pattern is more maintainable than ten copies of a call.”
The Pattern That Had Tests
Taraka knew that a pattern used by twelve provinces was a pattern that could break twelve provinces. Before releasing version 1.3 with the wider drainage channel, she ran tests on the pattern itself: "Given input province=test, capacity=small, does the pattern produce a drainage channel of the correct width?" The tests ran against a temporary build, checked the outputs, then destroyed the temporary build. The tests passed. Taraka released version 1.3. All twelve provinces called the new version on their next build. None broke. The pattern's value multiplied because its quality was verified before it was trusted. A tested pattern shared widely is safer than an untested pattern used once.
“The more widely a pattern is used, the more valuable its tests become.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Terraform modules are reusable units of infrastructure configuration. A module is a directory of .tf files with variables.tf (inputs), outputs.tf (outputs), and main.tf (resources). Callers reference modules using module blocks with source (local path, Git URL, or Terraform Registry) and version constraints. Module outputs expose computed values to callers without exposing internals. for_each on module blocks creates multiple instances from a map. The Terraform Registry hosts community and provider-maintained modules. Terratest lets you write Go tests that apply a module, validate outputs, and destroy. The discipline: design module interfaces for callers, not for implementors — stable inputs/outputs let internals evolve without breaking callers.