Thirty photos taken at handover, one reached the office
The owner photographed a handover himself: thirty pictures, one on the server. The other twenty-nine were gone, and the app had shown him nothing was wrong.
Topic
Concurrency & Retries
What happens when the same thing arrives twice, and which of the two wins.
13 articles
About this topic
Almost every article filed here starts the same way: something worked in testing and produced a duplicate in production. A payment provider sends two events for one payment. A queue redelivers. An operator reprocesses a batch. A client retries a request that had, in fact, succeeded. None of these are exotic, and a system that has not decided what it does about them has decided by accident.
The rule the collection keeps arriving at is that read-then-act is not a concurrency control, however careful the reading is. The condition has to be part of the write, and the caller that sees one affected row is the one allowed to continue. Everything else — uniqueness constraints, idempotency keys, replay-safe queues — is a backstop behind that.
Reps' orders marked rejected when nobody rejected them
A field app marked valid orders as rejected by the office after a brief server restart. The fix meant telling a failed connection from a refusal.
A child was served a quiz nobody had written
In a children's learning app, a parent published a seven-question lesson and the child got one question. Two faults combined, and a third was found beneath them.
Why your stock count can be wrong by a whole order
Stock was taken off at order and again at dispatch, so every shipped order was miscounted. Partial dispatch then let two drops ship the last unit.
Two tills sold the last case and stock fell only once
A sale, a production run and an adjustment each changed stock their own way. Only one took a lock, and the movement report was missing every sale.
Delivery app fails at the gate with no signal
A driver at a customer's gate with no signal got a spinner instead of a delivery form. Offline capture had been built, but nothing could reach it.
Field staff on poor signal: records lost or repeated
A mobile app on two bars of signal needs incremental sync. A timestamp cursor drops records silently or repeats them forever. The design that avoids both.
The driver handed the car back and collected nothing
A rental app told a driver nothing was owed at the kerb. Five thousand rupees was owed, then twenty. Forty-five thousand exposed across six bookings, and why.
Paid once, credited twice, then asked for the deposit again
The first real card payment through a rental system was credited double. The same customer was then asked for a deposit they had just paid. Both were one mistake.
He paid the deposit online and the counter asked again
A customer paid the rental and a five thousand rupee deposit online. The booking then asked him for five thousand more, and the expected deposit read ten thousand.
Reps took orders without signal, and some went missing
A field sales app treated every conflict reply as order already saved. Some saved orders showed as failed and others could be deleted from the phone.
One extension, charged twice: a mirrored total has no memory
A counter charge and an upstream re-price added the same 1,593 rupees an hour apart. Both stood, and the ledger held back the customer's deposit for it.
Why reps' orders vanish or double when they lose signal
A field app that works in the office can lose or duplicate orders out of signal. What has to be decided, in business terms, before an offline app is built.