Here, last write wins is the correct policy, and the reason is narrow enough to write down as a precondition: each of the five writers puts down values it read from Stripe moments before writing, so whoever wrote last is also whoever asked the authoritative system last [13]. The row is one answer, fetched five different ways, not a merge of five opinions about the customer.
That precondition is where I would push on the design. A webhook handler is the one writer that does not naturally re-read, because the delivered event describes the object as of the event. VoiceDash's developer, writing on dev.to, says all five paths write values read from Stripe a moment earlier [13], which is the version of the pattern that holds. Copy it without that, let the handler trust its payload, and a retried delivery can install stale status on top of a row the read-time reconcile just refreshed. The unique key retires duplicate rows, not ordering.
The constraint doing the load-bearing work is one schema line: `stripeSubscriptionId` is `@unique` [11], so the upsert's `where` clause targets the row by the external system's identifier [12]. That is the whole difference between cheap redundancy and an incident. Insert keyed on your own cuid instead, and five writers give you five rows [14].
The client-side poll is the part I liked most. `/api/stripe/verify-session` answers `202` with `retry: true` when Stripe reports the checkout complete but no subscription attached yet, and the browser retries up to five times, two seconds apart [8]. That is a ten second budget [16]. The lag that caused the original lockout was a couple of seconds [3]. So the retry window covers the observed gap with margin, and it covers it in the browser, where the customer is already staring at the screen waiting to be let in.
Then the bill. `syncSubscriptionFromStripe` runs on render of the agency layout and lists the customer's subscriptions [10]. Every agency page view is a Stripe API round trip before the layout resolves. The writeup describes no TTL, no freshness check against `currentPeriodEnd`, and no short-circuit when the cached row is comfortably active, which is the first optimisation I would want and the one that is easiest to postpone until someone complains about page loads.
There is a second cache underneath, and it is graded. The workspace row carries a denormalized `plan` column that the limit checks read, so counting clients against a plan does not require a join to billing, while access is gated on the subscription row itself [15]. Staleness in the plan column costs a wrong limit. Staleness in the subscription row costs a lockout [2]. Different tolerances, different reads.
Transfer conditions are specific. Stripe hands you a stable unique id you cannot mint yourself, the cached state is a handful of scalar fields [11], and refetching is a cheap list call [10]. Trial extensions you grant by hand, or seat entitlements your own code computes, have no upstream to re-read. For those your table really is the record, and the tutorial advice of one canonical writer is right again.
