B2 · The Elixir BCS Core
The law, landed on OTP and ETS.
The crucial chapter, in six modules: a system as an OTP application, its state in property stores on ETS, those values in a CHAMP persistent map, entity types composed from archetypes, relations that are systems, and a gated boundary.
Six modules. B2.1 is built in six dives and B2.2 to B2.6 in three each. This is the core the bus, the cache, the floor, and the Codemojex game all stand on.
The six modules
content/bcs2.1.md — bcs2.6.mdA System Is an OTP Application
Boundary, supervision, ownership, and the source behind them: the export list is the surface, the table is :private, the supervisor owns existence. Six dives — three on the shape, three walking the real code.
Property Stores on ETS
Three stores under one tree, the 14-byte branded id the only key, chronology read off the ordered keyspace with no timestamp column — page_desc and window. A player’s state, addressed by name.
The CHAMP Property Database
A persistent hash-array-mapped trie: structural sharing as the snapshot mechanism, the contract hash as the placement function, the crossover against a flat table stated both ways. Game snapshots shared, not copied.
B2.4Archetypes and Composition
Property inheritance as data under an archetype namespace, the composite read at request time by a pure fold — reuse without a class diamond. A tile or a player composed from parts.
B2.5Relations Are Systems
The edges store: tuple-keyed relations, both ends gated, dual private indexes for traversal from either end. Player-in-room and tile-owned-by-player, each a system of its own.
B2.6Gates and Acceleration at the Boundary
The namespace gate that admits one kind and collapses the rest to invalid, and an optional native codec that accelerates the contract with a pure-Elixir fallback proven equal at boot. The hot path of a live game.
A module card becomes a link when its pages ship. The dives per module are fixed in the chapter spec; the reading order is the arc above. B2.1, the foundation, is built — in six dives.
Evidence
echo_data · the committed treeEvery module draws from real source under echo_data — bcs/property_store.ex and its supervisor.ex, the CHAMP map, the edges store, the gates — and B2.1 shows three of those files in full. The discipline holds: a number appears in a figure only if a committed output asserts it, and the only contract figure on these pages is the placement vector the runtime checks at boot, placement(USR0KHTOWnGLuC) = 234878118. Where a measured line is claimed, it rides a committed benchmark, not this page.
Up next
where the core leadsThe Elixir core is the floor the rest of the course stands on. B3 puts these systems on a Valkey-native bus; B4 fronts their state with the declared near-cache; B5 makes that state durable on the Graft floor; and B7 runs the Codemojex game across all of it — rooms as systems, moves as messages about ids, state in stores, settlement on lanes. Start with B2.1, the system itself.
The doors
the sibling coursesEchoMQ — the protocol, in depth
The bus B3 narrates, taught rung by rung: the keyspace, the Lua inventory, and the 3.0 Stream Tier — XADD, XREADGROUP, XACK — with conformance on Valkey.
Redis Patterns Applied
The substrate patterns under the bus: sorted sets, atomic Lua moves, locks, and streams — the judgement layer.
/echo-persistenceEcho Persistence — the durable floor
Beneath the volatile tiers: the Graft page engine built twice, the commit-LSN loop, and the stream archive on Tigris. Where Part I says state lives somewhere, this says where it lives durably.
References
sources · relatedSources
- Erlang/OTP — the gen_server behavioura system as a process: one mailbox, one private state, a message-only surface
- Erlang/OTP — the ets modulethe :private :ordered_set table a property store owns behind its boundary
- Steindorfer & Vinju — CHAMP (OOPSLA 2015)the persistent hash-array-mapped trie holding a store's values
Related
- BCS — the course homethe law, the id anatomy, the chapter map
- Echo Persistencethe durable floor beneath the bus