Paweł ('Pavel') Strzałkowski's wroclove.rb 2022 talk introducing event sourcing in Ruby via the Eventide project. Opens by contrasting the classic relational storage of a customer 'Mary' (users, orders, interests tables with only the final state) with a view of Mary as the full sequence of changes she made (account created, first/last name updates, items added and removed, interests replaced). Defines event sourcing as 'a pattern for storing data as events in an append-only log' — events are stored in real-time order, never modified, and the current state is a transient projection. Motivates the pattern with three examples: a document approval flow where the final 'approved' column hides who keeps getting rejected; two shopping carts selling the same items but revealing very different buyer information (abandoned line items, hesitation, marketing value); a cargo ship whose current-location field may never reveal that every boat silently passes through the Bermuda Triangle. Key maxim: 'don't lose data if you don't have to', because you cannot put a future price on the data you didn't know you should have stored. Introduces Eventide: a Ruby toolkit for event-sourced autonomous services that ships with MessageDB (a Postgres-backed message store installed via a gem and CLI) and TestBench (its own test framework — 'forget anything you've ever learned about RSpec'); works with any Ruby project including Rails. Walks through the core concepts: events and commands are both messages (events = something that happened, commands = a request to do something) defined as small Ruby classes with attributes; streams organize messages (command stream vs event stream for an entity like order-7); MessageDB is a single-table Postgres implementation with columns global_position, position, time, stream_name, type, data (JSON attributes), metadata (causation/correlation) and UUID message id; consumers are processes (like a Sidekiq worker) that read from a category, apply business logic via handlers (one per message type), and write new messages; this implements pub/sub — publishers and subscribers are mutually unaware and communicate only via stream categories. Projection is defined as folding an event stream from an empty entity through every event into current state, used (a) by handlers to make decisions (e.g. enforcing a 'max 2 line items' invariant) and (b) to build read models in any database (relational, graph, document) so the system can query lists of orders efficiently — introducing a natural split between writes (commands) and reads (projections), with eventual consistency. Shows Eventide code: a command/event class with attributes, an Account class with pure properties/behavior, a Projection class with `apply` blocks per event type, and an Entity Store binding entity + projection; an interactive test CLI writing a Deposit command, a Viewer web UI showing streams and messages, and an event stream built after starting a consumer. Runs a sequence of deposits (11) and withdrawals (10) showing the last withdrawal rejected for insufficient funds. Closes with a more complex funds-transfer example across two accounts involving an 'initiated' event, a withdrawal command, a subscribed internal withdrawal event, a deposit command, an internal deposited event, and a final 'transferred' event — with a nod to idempotence as an omitted complication. Connects event sourcing to Rails: require the account component gem to issue commands from a Rails app; or simply flip control flow at the end of a Rails service by publishing an event that a consumer handles asynchronously, decoupling the next step and achieving event-driven architecture. Recommends Eventide's website and Slack, a Scott Bell presentation ('beautiful mind, changes how you think about autonomous services'), and Greg Young's foundational talk on event sourcing. Q&A covers: meaning of the sequence number in projection code (position within the stream — a version that lets you replay state at any past point); whether a single user action can update many order projections (projection operates on one stream at a time; joining streams is doable but non-trivial); GDPR and losing data on purpose (keep sensitive data in a separate stream like 'user profile' that can be dropped, or encrypt and lose the key — design for it up front); acknowledging that in practice we consciously choose what to store vs drop for revenue, debugging, cost and legality, but warning that most teams lose data unintentionally (e.g. never analyzing items removed from abandoned carts); NoSQL/MongoDB/DynamoDB vs Postgres for storing events and handling event versioning ('two beers and we can talk'); how often to project (business decision — explain to stakeholders that UI data is never truly fresh, a few seconds of eventual consistency is usually fine, while business-critical decisions use fresh projections computed at decision time from snapshots); Eventide ships a default snapshotting policy (~100 events).