Skip to content

PATTERN Cited by 1 source

Unified typespace consolidation

Shape

When two (or more) subsystems independently define parallel type definitions for the same conceptual types (boolean, number, color, …), consolidate them into a single typespace that both subsystems reference. The prior state is duplicate types; the new state is one canonical type set. Binding, validation, conversion, and serialization all route through the canonical set.

Problem this addresses

Accidental complexity ratchets in every time two subsystems add the same type in parallel:

  1. Doubled implementation cost per new type. Adding date to system A and system B means writing two validators, two serializers, two UI pickers.
  2. Cross-subsystem bindings are structurally impossible. If system A wants to reference a type-X value from system B, the types don't match because they're nominally distinct. You can't bind "a component property" to "a number variable" when component-property-number and variable-number are different types.
  3. Drift over time. Type-specific behaviors (comparison rules, coercion rules, default values) diverge between the parallel definitions, often without the authors noticing.
  4. Every new subsystem adds an Nth+1 parallel definition. A third parameter system would inherit two existing type vocabularies and create a third. The cost scales in N², not N.

Mechanism

  1. Inventory the parallel type definitions. Enumerate each subsystem's type vocabulary and align them to a canonical set.
  2. Define the single canonical typespace with concrete data representations, validation, serialization, conversion rules.
  3. Migrate each subsystem's type references to point at the canonical types. Often this lands as a refactor that re-aliases VariableType.BOOLEAN = Type.BOOLEAN, then deletes the alias once call sites are migrated.
  4. Migrate existing stored data. Any persisted schema that encoded "this value is a VariableType.BOOLEAN" needs to be rewritten (or read compatibly) as "Type.BOOLEAN." This is where migrations get expensive.
  5. Add cross-subsystem bindings as the first new capability that wasn't structurally possible before. In Figma's case this was component-property-to-variable binding.

Canonical instance

Figma's 2024–2026 unification of component-property types (ComponentPropType.BOOLEAN, …) and variable types (VariableType.BOOLEAN, …) into a single typespace (Source: sources/2026-04-21-figma-parameter-architecture-unification). The post names the exact ratchet — "adding support for a new type required implementing it twice: once for variables and once for component properties" — and identifies cross-system binding as the feature that was "otherwise impossible." Consolidation unlocked component-property-to-variable binding as the first new capability that proved the architecture change.

When to apply

  • Two+ subsystems handling the "same kind of thing" with parallel types.
  • A planned cross-subsystem feature that requires their types to interoperate.
  • A prospective third subsystem the platform wants to host without paying a third duplication cost.

When not to apply

  • The subsystems' types are nominally similar but carry different semantics (e.g. Duration in two services where one allows negatives and the other doesn't). Consolidation would force a semantic merge that isn't design-safe.
  • The migration cost for existing persisted data exceeds the future cross-subsystem-feature value. The pattern has to be justified by concrete capability unlocks, not purely as a cleanup.
  • patterns/single-source-service-definition is the same shape one abstraction up: one authoring surface per service instead of parallel authoring across YAML / IAM / Terraform.
  • patterns/presentation-layer-over-storage (AWS S3 Files) is the same shape at the data-presentation layer: one storage substrate, many typed presentations, propagated from one canonical object model.
  • patterns/runtime-orchestration-unidirectional-flow is the same-shape consolidation on the runtime axis (Figma 2026 Materializer project): parallel ad-hoc subsystem schedulers unified under one shared orchestration layer, back-dirties eliminated, data flow pushed toward unidirectional. Typespace consolidation (data-model axis) + runtime-orchestration consolidation (execution axis) are the two complementary halves of Figma's 2024–2026 client-architecture cleanup.

Seen in

Last updated · 200 distilled / 1,178 read