CRDT (Conflict-free Replicated Data Type)
Related service Custom software · everything else
DEFINITION
Conflict-free Replicated Data Type. A data structure (counter, set, map, ordered text) that mathematically guarantees that if many peers edit it offline and sync in any order, the result is the same everywhere with no manual conflict resolution. Classic demo: the synced multiplayer cursor, where colleagues type in the same Figma or Notion document at the same time, characters do not overwrite each other, and cursors move live. Problem solved: last-write-wins and manual merge are weak primitives for collaborative editing, offline-first apps, and replicas running at the edge. Two schools: state-based (CvRDT, states can be merged) and operation-based (CmRDT, operations are commutative). In production: Yjs, Automerge, the Loro Rust library, plus Liveblocks and PartyKit as a service. The price: bigger payloads (operation logs) and you need garbage collection.
- Docker→
We package an app with its dependencies into an image, which runs as a container - identical on your laptop and in production. "Works on my machine" stops being an excuse.
- CI/CD→
Continuous Integration / Delivery: every commit is automatically built, tested and (optionally) deployed. This pipeline lets us ship safely many times a day, without manual mistakes.
- Blue-Green Deployment→
We run two identical environments: blue is live, green is the new version. Once green is verified we flip traffic to it; on trouble we flip back instantly. Zero-downtime releases with instant rollback.
- Horizontal Scaling→
We add more machines/instances (scale out) instead of one bigger box (vertical, scale up). For stateless services this wins: cheaper, more elastic, no ceiling. State goes to a separate store.
- Load Balancer→
Distributes incoming traffic across multiple instances - the front door that gives you redundancy and smooth scaling. Health checks remove dead instances, so one failure stays invisible to users.
- Distributed Tracing→
We follow one request across every service using a trace ID (e.g. OpenTelemetry). In a microservices system this is how we pinpoint which service slowed down or failed - no guessing.
No posts cite this term yet.