[Avg. reading time: 10 minutes]

Consistency Models

Eventual Consistency

A model where updates to data propagate across distributed nodes asynchronously. Temporary inconsistencies are allowed, but all replicas will eventually converge to the same state.

Example A smart vehicle updates its GPS location while offline. The cloud reflects the update once connectivity is restored.

Use Cases

  • Smart home devices
  • Vehicle tracking systems
  • Environmental monitoring

Limitations

  • Not suitable for financial systems or real-time critical decisions

Read-Your-Writes (RYW)

Once a client performs a write, all subsequent reads by that client must reflect that write.

Example A user turns OFF a smart light and immediately sees the updated OFF state in the app.

Use Cases

  • Device control systems
  • User-facing dashboards

Limitations

  • Requires session or client-level tracking

Monotonic Reads

Once a value is read, subsequent reads should never return an older value.

Example

TimeReading
10:00102 kWh
10:01103 kWh
10:02101 kWh ❌
10:03104 kWh

Use Cases

  • Energy meters
  • GPS tracking
  • Time-series monitoring

Limitations

  • Requires ordering guarantees across replicas

Causal Consistency

Ensures that causally related operations are observed in the correct order across the system.

Example Door opened > Alarm disabled
If reversed, system behavior becomes incorrect.

Use Cases

  • Security systems
  • Workflow-based automation

Limitations

  • Harder to implement than eventual consistency

Last Write Wins (LWW)

When multiple updates occur, the update with the most recent timestamp overwrites previous values.

Example Two users control the same smart light. The latest command determines the final state.

Use Cases

  • Smart home controls
  • IoT dashboards

Limitations

  • Risk of losing valid updates due to clock skew

Optimistic Concurrency

Allows multiple updates without locking resources. Conflicts are detected after execution, and one operation may need to retry.

Example

item_iditem_nmstock
1Apple10

Two users update simultaneously:

  • +5 and -3 applied concurrently
  • Conflict detected > one retries

Use Cases

  • Low-conflict environments
  • User-driven updates

Limitations

  • Not suitable for high-frequency concurrent writes

Strong Consistency

All reads return the most recent write immediately across all nodes.

Example Bank transaction reflects instantly across all systems.

Use Cases

  • Financial systems
  • Critical control systems

Limitations

  • Higher latency
  • Reduced availability in distributed systems

Session Consistency

Guarantees consistency within a single session but not across different clients.

Example A user sees consistent device state during a session, but another user may see stale data.

Use Cases

  • Mobile apps
  • User-specific IoT dashboards

Limitations

  • Not globally consistent

Bounded Staleness

Allows reads to lag behind writes by a defined time or number of versions.

Example A dashboard may show data up to 5 seconds old.

Use Cases

  • Monitoring dashboards
  • Analytics systems

Limitations

  • Requires defining acceptable staleness window

Term Mapping in IoT Context

ConceptRelevance in IoT
Eventual ConsistencyEdge devices syncing after offline periods
Read-Your-WritesImmediate feedback for device control
Monotonic ReadsPrevents backward movement in sensor readings
Causal ConsistencyMaintains correct event order in automation
Last Write WinsResolves conflicting device updates
Optimistic ConcurrencyHandles rare update conflicts
Strong ConsistencyRequired for critical operations
Session ConsistencyEnsures stable user experience
Bounded StalenessBalances freshness and performance

#consistency #eventualVer 6.0.23

Last change: 2026-04-16