How a Tiny Team Shipped Like a Big One

The story

It’s a year later. Pemberton & Crumb now power hundreds of pickle shops. Dana still leads engineering — a team of five, not five hundred. And yet their platform does the things you’d expect from a company ten times the size: it’s auditable, multi-tenant, observably healthy, and it survives its own busiest days.

This used to seem impossible. Every guarantee in that list — the audit trail, the tenant isolation, the reliable messaging, the graceful failure — had, in the earlier stories, arrived as a catastrophe first and a fix second. The missing $4,000. The pickles that never shipped. The tenant who saw a competitor’s orders. Each one had cost a bad night, an awkward email, or both.

What changed wasn’t that the team got bigger. It’s that they stopped rebuilding those guarantees by hand for every feature, and started getting them from the framework by default. A new feature at Pemberton & Crumb is now a command and a handler dropped into a folder — and it inherits, for free, everything the previous nine stories had to suffer to earn.

Crumb, reviewing the quarter, said: “We ship like a big company.” Dana, who remembered Pickle Friday, just nodded and ordered another coffee.

How it all fits together

The earlier stories each fixed one problem. The real payoff is that they’re not nine separate tools — they’re one coherent stack where a single feature gets all of it at once. Walk a single order through Relay:

1. A PlaceOrderCommand arrives. (001) It’s one message with one handler — no 2,400-line OrderService.
2. Relay’s pipeline checks authorization before the handler runs (009) — the same check whether the order came from a web request, a saga, or a job. And the tenant is resolved and enforced, so this order can only ever touch its own shop’s data. (007)
3. The handler records what happened as events, not overwritten state — so a year from now you can still answer “how did this balance get here?” (002)
4. In one atomic transaction, Relay commits the state, the events, and the “tell the warehouse” message into the outbox — no dual-write, no missing pickles. (003)
5. The warehouse consumes that message through an inbox, so a redelivery doesn’t charge or ship twice. (004)
6. The multi-step fulfilment runs as a saga with compensations, so a failure on step three unwinds cleanly and refunds the customer instead of stranding their money. (008)
7. Every external call is wrapped in retries, timeouts, and circuit breakers, so one slow dependency degrades gracefully instead of melting the platform. (005)
8. And the whole journey emits traces and metrics under one correlation ID, so when something does go wrong, you find it in minutes, not at 4 a.m. (006)

// A new feature is still just this. Everything above comes with it, by default.
[RequireRole("Customer"), TenantScoped]
public sealed record PlaceOrderCommand(IReadOnlyList<Line> Lines) : ICommand<OrderConfirmation>;

That’s the quiet thesis of all ten stories: the hard parts of distributed systems shouldn’t be re-earned, feature by feature, disaster by disaster. They should be the floor you build on. A team of five gets to spend its energy on pickles — the actual product — instead of rebuilding outboxes and tenant filters and saga orchestration that a thousand teams before them have already gotten wrong.

What it costs you to ignore this

• You pay the “distributed systems tax” over and over. Without a unifying framework, every feature re-implements (and re-bugs) the same plumbing.
• The guarantees drift apart. Hand-rolled auth, audit, and tenancy end up applied inconsistently — strong on the features someone remembered, absent on the ones they didn’t.
• Small teams can’t punch above their weight. The reason five people can’t usually ship big-company guarantees is that they’re rebuilding them by hand; remove that, and they can.
• You learn each lesson the expensive way. Stories 002 through 009 are tuition. You can pay it in incidents, or inherit it from the framework.