تخطَّ إلى المحتوى
SteveTechArcSteveTechArc Courses

Transactions, Concurrency, and Reliability

هذا المحتوى غير متوفر بلغتك بعد.

Chapter 11 of Data Architect, Part 2: Architecting at Scale. Previous: Migration and Synchronization.

A design can work perfectly for one user and fail for a few hundred. Nothing about each save changes; what changes is how many arrive at once. Then UNABLE_TO_LOCK_ROW shows up at peak, someone adds retries, and the retries start creating duplicates.

Yellow robot arms work side by side along one production line, each fitting a copper sleeve into its own steel part, all at the same time.

Image generated with AI.

This chapter is about that moment: what a save really locks, why it collides, how to design the collision out, and how to make sure that when something fails anyway, the second attempt does no harm.

One example runs through all three modules: Steve Trucking at 4 p.m. Across nine distribution centers, 330 trucks are on their last stops, and crews are tapping Delivered at the same moment. Every Work Order is a different record, but they all point at the same Manifest. Then, in module 3, a damage credit to a Retail Partner whose answer gets lost on the way back.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • One save is rarely just one record. Draw the lock footprint: the record, the parents it points to, a roll-up’s parent, and whatever automation touches.
  • Salesforce is optimistic at the user level and pessimistic at the transaction level, and hopefully that transaction lasts about a second. Another transaction waits up to 10 seconds for a lock, then fails.
  • A lookup still locks. What a master-detail roll-up adds is more work while the lock is held: the parent’s own save runs inside the child’s.
  • Different records, one intersection. A crowded parent turns hundreds of independent saves into one line.
  • Lock in the same order everywhere, or two trucks end up stuck in the intersection.
  • Work four levers before you retry: reduce the footprint, shorten the transaction, partition the work, control concurrency.
  • Serialize only the work that competes: one line per parent, the lines side by side.
  • A timeout isn’t a failure; it’s an unknown. If the client owns the retry, the architecture must make the retry safe.
  • Record identity and operation identity are different. An action that can legitimately repeat, like a credit, needs its own key, the same on every retry.
  • “Exactly once” is a dangerous phrase. Design for the right business result, and let automatic retry stop somewhere visible.

The path through this chapter

Section titled “The path through this chapter”

Three modules, each standing on its own.

  1. The Lock Footprint of a Save. The 4 p.m. rush; optimistic and pessimistic locking; what one Work Order save locks; lookups, roll-ups and the order of execution; one intersection; deadlocks and lock order.
  2. Designing Out Lock Contention. Find the shared lock; observe before you guess; four levers, applied to the Manifest: stop recounting it inside every save, keep the count seconds behind, one line per Manifest, fewer workers; then retry.
  3. Safe to Retry. The credit that went out twice; failure versus uncertainty; record and operation identity; which failures to retry, with backoff and jitter; proof of delivery, done right; when retry must stop.

What an architect decides here

Section titled “What an architect decides here”
  • What each business transaction really locks, beyond the record on the screen.
  • Which relationships, roll-ups and automation belong inside the save, and which can run just after it.
  • How the work is grouped and how much runs at once, so only competing work waits.
  • Which operations are harmful to repeat, and which identity makes each one safe.
  • Which failures are retried, how, and for how long, and where the work goes when retry stops.
  • What an agent’s actions must guarantee before an agent may call them.

Beyond the exam: agents add writers that query, act and retry without getting tired. The platform’s locking rules don’t change; the number of concurrent actions does. Give agents focused, established actions with safe retries. Each module ends with what AI changes.

Explore

Section titled “Explore”

Next: Data Security for Humans, Applications, and Agents