Edge Data Consistency
The consistency model available when data is replicated to many edge locations, where strong consistency would eliminate the latency benefit that motivated the edge.
The tension is unavoidable and follows from physics. Placing data at fifty edge locations to serve reads in five milliseconds means a strongly consistent write must coordinate across those locations, which costs a round trip to a quorum and reintroduces exactly the latency the edge was built to remove.
So edge data is almost always eventually consistent, and the architectural work is deciding which data can tolerate that and what the propagation delay is allowed to be.
The pattern that works is asymmetric: read locally, write centrally. Reads are served from the nearest replica at edge latency; writes go to a home region and propagate outward. This suits the overwhelmingly read-heavy workloads that motivate edge deployment — configuration, feature flags, content, product catalogue, personalisation segments — and it keeps a single authoritative writer, which avoids the conflict resolution problem entirely.
What must not be pushed to the edge without a great deal more thought: anything with a global invariant, such as inventory counts, account balances, rate limits enforced as a hard cap, or uniqueness constraints. Distributed rate limiting at the edge is the case people underestimate — a limit of 100 enforced independently at fifty locations is a limit of 5,000, and discovering that during an abuse incident is the usual way it is learned.