event-driven – Page 5 – Türker Yıldırım

Writing the row and the event in the same transaction

NoteNovember 7, 20192 min read

Saving a record and publishing an event are two systems and cannot be made atomic, so either the row exists with no event or the event was sent…

A read model is a copy, and copies need a story about staleness

NoteOctober 17, 20192 min read

Replicating the data a second service reads removes the shared schema and introduces a lag, and the lag is a product decision rather than a technical detail. Storing…

Messenger, and the queue that is part of the framework

Deep diveJune 25, 201910 min read

4.3 made Messenger stable, and dispatch stopped being the same decision as transport. A message, a handler, and routing declared in configuration.

Two services, one database, and the year it took to separate them

Deep diveMarch 13, 20199 min read

Two deployables writing the same tables is one service with extra steps. Deciding who owns them is the whole decision, and the intermediate state lasts.

Redis streams, and the broker you might not need

Deep diveOctober 24, 201810 min read

5.0 shipped in October with a log-structured type and consumer groups. A list has no acknowledgement, which is why a crashed consumer loses the message.

An event carries facts, a command carries an instruction

NoteSeptember 5, 20182 min read

The naming decides the coupling. ReserveInventory names a recipient and expects an outcome; OrderPlaced names neither, so a second consumer can be added without touching the publisher. Past…

The outbox pattern, in the smallest version that works

NoteMarch 13, 20182 min read

Writing a row and publishing an event are two systems, and there is no way to make them atomic — so either the row exists and no event…

Event versioning is harder than API versioning

NoteDecember 16, 20172 min read

An API version can be retired once the clients have moved. An event may be sitting in a queue, or in an event store, published by a version…

A topic exchange is a routing decision you can change later

NoteOctober 3, 20171 min read

Publishing directly to a queue name binds the producer to the consumer topology, so adding a second consumer means changing the publisher. A topic exchange puts a routing…

A saga is a workflow with compensation, not a transaction

NoteSeptember 28, 20171 min read

A distributed transaction is not available, so the pattern is: do each step, and if a later one fails, run compensating actions to undo the earlier ones. Compensation…