Event-Driven-Architecture on Brian Faust

A Process Manager Remembers What the Queue Cannot

Fri, 01 Sep 2023 00:00:00 +0000

An order is paid at 10:00. Inventory is reserved at 10:01. The warehouse does not respond until 14:30. Shipping fails the next morning, after two worker deployments and a payment-provider timeout.

No request, transaction, or queue worker owns that whole timeline. Chaining jobs can move execution from one step to the next, but the queue does not know whether the business process is waiting, complete, compensating, or stuck.

A Process Manager exists to remember that state and decide what should happen when a relevant message arrives. Its value begins where call-stack control ends.

An Outbox Moves the Failure Window

Tue, 01 Aug 2023 00:00:00 +0000

Place an order, commit it, then publish OrderPlaced. If the broker rejects the send, the order remains placed and nothing durable says publication is still required.

Reverse the sequence. Publish OrderPlaced, then commit the order. If the database rolls back, the broker now carries a fact which the source database never accepted.

A transactional outbox changes the sequence again. Insert the order and a pending message in one local transaction. Rollback removes both. Commit makes both durable. A separate relay can keep trying the message after the request which placed the order has ended.

Publishing Events Is Not Event Sourcing

Sat, 01 Jul 2023 00:00:00 +0000

Two wallet applications accept the same credits and publish the same FundsCredited event. Both end with a balance of 3,500 cents. Both can update a listener-owned read model.

Now delete the wallet row and ask each application to recover.

The first application cannot. Its wallets.balance_minor column was the authoritative value. The events were notifications sent after accepted changes, and their payloads do not contain enough information to reconstruct the balance.

A Domain Event Is a Fact, Not a Question

Thu, 01 Jun 2023 00:00:00 +0000

An order cannot be placed until a credit policy accepts it. The handler needs that answer before it can continue:

if (!$this->credit->allows($customerId, $amountCents)) {
 throw new CreditRefused();
}

$order->place($customerId, $amountCents, $placedOn);

Turn that call into a CheckCredit event and the question does not disappear. It becomes harder to see. The handler still needs an answer, but an event dispatcher normally gives it a list of listeners, not a typed decision. Now the code needs a mutable payload, stopped propagation, or some other private convention to recover the response.

EventStorming Finds Disagreement Before It Finds Services

Tue, 01 Feb 2022 00:00:00 +0000

Ask sales, support, finance, and engineering when an order becomes cancelled and the answers may sound compatible until they share a wall.

Sales says cancellation happens when the customer asks. Support says it happens after a case is approved. Finance says a paid order remains active until the refund clears. Engineering points to a cancelled_at column written before the payment provider responds.

That disagreement is not workshop noise. It is the model.