Databases on Brian Faust

Eager Loading Is Not a Query Shape

Sat, 01 Feb 2025 00:00:00 +0000

A catalogue endpoint returns 25 names and the number of active variants behind each one. The first implementation runs 26 queries. Adding with('activeVariants') reduces that to two.

The N+1 defect is gone. The new implementation still hydrates 1,250 Variant models, including a synthetic 4 KiB metadata column, to produce 25 integers.

Eager loading solved the repeated-query shape. It did not ask what the response needed. That is the larger decision: queries, selected rows and columns, hydrated models, serialization, and the database plan all belong to one read path.

CQRS Starts When Reads Need a Different Model

Mon, 01 May 2023 00:00:00 +0000

An order-details page needs customer name, payment status, shipment progress, line totals, tax labels, and the latest support case. The write model needs to protect payment, cancellation, and fulfilment invariants.

Trying to make one Eloquent graph serve both jobs creates a familiar mess: relationships exist for screen composition, write methods expose persistence concerns, and every request loads a different subset of a model that is never quite complete.

That tension can justify different read and write models. It does not automatically justify two databases, an event store, a command bus, or eventual consistency. CQRS is the model split; the infrastructure is a separate set of decisions.

A Version Column Is Not Concurrency Control

Sun, 01 Jan 2023 00:00:00 +0000

A capacity pool has ten units available. Two workers load it before either one writes:

worker A loads: version 0, reserved 0
worker B loads: version 0, reserved 0

worker A allocates 6 to allocation-a
worker B allocates 6 to allocation-b

Both decisions pass the aggregate’s rule. Each worker sees ten remaining units. They cannot both belong to one ordered history: after either allocation, only four remain.