The Timeline Tango: Comparing Three Resolution Architectures That Dance at Different Speeds

Every system that processes events in order eventually faces a fundamental question: what happens when two things happen at the same time, or the order is ambiguous? The answer defines your resolution architecture—the set of rules and mechanisms that turn a messy timeline into a consistent story. Teams often pick one based on a quick proof of concept, only to discover later that their choice dictates everything from latency to debugging complexity.

This guide compares three common resolution architectures: the Lock-Step Sequencer, the Optimistic Merger, and the Eventual Convergence Engine. We'll walk through how each one works, where it excels, and the hidden costs that typically surface after the first production incident. By the end, you'll have a decision framework that matches architecture to your actual constraints—not just the hype around the latest approach.

1. Where These Architectures Show Up in Real Work

Resolution timeline architectures are not abstract theory—they appear in nearly every distributed system that cares about event order. In version control systems like Git, the merge algorithm is a resolution architecture. In collaborative document editing (Google Docs, Figma), the Operational Transformation or CRDT engine is one. In event-sourced systems, the event store's ordering and conflict resolution logic is the architecture. And in CI/CD pipelines, the way you handle concurrent commits or test results is a form of timeline resolution.

The choice matters because it directly affects user experience and operational burden. A Lock-Step Sequencer, for example, ensures strong consistency but introduces waiting—every participant must synchronize before proceeding. This is fine for a small team editing a shared config file, but it becomes a bottleneck for a global user base. An Optimistic Merger lets everyone work independently and reconcile later, which feels fast but can lead to painful conflict resolution sessions. An Eventual Convergence Engine aims to avoid conflicts altogether by using mathematical guarantees, but it often adds complexity in data structure design and debugging.

We've seen teams adopt one architecture because it worked for a well-known product, only to find that their own workload patterns—high write contention, large payloads, or strict ordering requirements—made it a poor fit. The goal of this guide is to help you recognize which pattern matches your scenario before you commit to an implementation.

Common Domains and Their Default Choices

In practice, certain domains gravitate toward specific architectures. Real-time collaboration tools often start with Operational Transformation (a form of Optimistic Merger) because it feels responsive. Distributed databases lean toward Lock-Step Sequencers (via consensus protocols like Raft or Paxos) for strong consistency. Peer-to-peer sync tools frequently adopt Eventual Convergence (CRDTs) to avoid central coordination. But these defaults are not laws—they are starting points that should be questioned based on your specific constraints.

2. Foundations That Readers Often Confuse

Before comparing architectures, we need to clarify three concepts that frequently cause confusion: the difference between conflict detection and conflict resolution, the role of causality versus total order, and the distinction between operational and state-based approaches.

Conflict detection vs. resolution. Detection is the act of noticing that two events cannot both be applied in their original form—for example, two users editing the same line of a document. Resolution is the set of rules that decides what the final state should be. Some architectures detect conflicts early and block (Lock-Step), others detect them late and ask for help (Optimistic Merger), and others avoid detection by designing operations that commute (Eventual Convergence). Confusing these two leads to misapplied solutions: a team might implement a sophisticated conflict detection system when what they actually need is a way to make operations commutative.

Causality vs. total order. Causality means that if event A caused event B, then A must appear before B in the timeline. Total order means that every pair of events has a defined order, even if they are causally unrelated. Lock-Step Sequencers enforce a total order for all events, which is simple but expensive. Optimistic Mergers often rely on causal order only, allowing unrelated events to be reordered. Eventual Convergence Engines typically work with partial orders and rely on mathematical properties to guarantee convergence regardless of order. Teams that assume they need total order often over-engineer their system; teams that ignore causality risk violating user expectations.

Operational vs. state-based. Operational approaches (like OT) transform operations so that they can be applied in any order and produce the same result. State-based approaches (like state-based CRDTs) merge entire states rather than individual operations. The choice affects network bandwidth (operations are usually smaller than full states) and complexity (state-based systems are easier to reason about but may require more storage). Many teams conflate the two, leading to designs that inherit the worst of both worlds.

3. Patterns That Usually Work

Each architecture has a sweet spot where it performs well and is relatively easy to operate. Here are the patterns we see working in practice.

Lock-Step Sequencer: Best for Small, Trusted Groups

When you have a small number of writers (say, fewer than 10) and a low tolerance for inconsistency, a Lock-Step Sequencer is hard to beat. The classic example is a leader-based consensus system where every write goes through a single node that assigns a monotonically increasing sequence number. Readers can then process events in order without worrying about conflicts. This pattern works well for configuration management, financial transaction logs, and any scenario where the cost of inconsistency is high and the cost of waiting is low.

The key to making this pattern work is to keep the write path simple and the sequencer stateless (or easily replicated). Avoid adding complex conflict resolution logic at the sequencer level—if two writes conflict, reject one and let the client retry. This keeps the system predictable and easy to debug.

Optimistic Merger: Best for Collaborative Editing with Low Contention

For applications where users work independently most of the time and conflicts are rare, an Optimistic Merger (like Git's merge or OT) provides a responsive experience. Users see their changes immediately, and the system reconciles differences in the background. The pattern works best when operations are fine-grained (character-level edits rather than paragraph-level) and when the merge algorithm is well-tested for the specific data type.

A common successful pattern is to use operational transformation with a central server that sequences operations but does not block on conflicts. The server applies operations in the order they arrive, transforms conflicting operations so they remain consistent, and broadcasts the result. This gives the illusion of real-time collaboration while maintaining a single source of truth.

Eventual Convergence Engine: Best for Offline-First and Peer-to-Peer Systems

When users need to work offline or when the system must operate without a central coordinator, an Eventual Convergence Engine (typically based on CRDTs) is the natural choice. The pattern works by designing data types where operations commute—meaning that applying them in any order leads to the same final state. This eliminates the need for conflict resolution entirely. Successful implementations use well-known CRDTs like LWW-Register (last-writer-wins register) or G-Counter (grow-only counter) and avoid custom types that may not converge correctly.

The pattern works best when the data model is simple (counters, sets, single-value registers) and when the network is unreliable or high-latency. It is less suited for complex nested structures or when the system needs to enforce invariants that depend on event order.

4. Anti-Patterns and Why Teams Revert

Even when an architecture is theoretically sound, teams often abandon it due to practical issues. Here are the most common anti-patterns we've observed.

Lock-Step Sequencer: The Bottleneck Blind Spot

The most common anti-pattern is treating the sequencer as a simple component that can be scaled horizontally. In reality, the sequencer is a single point of coordination—adding replicas does not increase throughput because every write must still go through the same ordering logic. Teams often try to shard the sequencer by partitioning data, but this introduces cross-shard ordering problems that are harder than the original problem. The result is a system that is slower than expected and difficult to scale. Many teams revert to an Optimistic Merger after hitting throughput limits, only to discover that their conflict rate is now unmanageable.

Optimistic Merger: The Conflict Avalanche

Optimistic Mergers work well when conflicts are rare, but they fail catastrophically when conflict rates rise. A common anti-pattern is to ignore the conflict rate until it becomes a problem—for example, a collaborative document that starts with two editors and grows to fifty. The merge algorithm that worked for two users now produces conflicts on every save, and users spend more time resolving conflicts than editing. Teams often try to fix this by improving the merge algorithm, but the real solution is to reduce the conflict rate by changing the data model (e.g., using finer-grained operations) or by switching to a Lock-Step Sequencer for high-contention data.

Another anti-pattern is relying on automatic conflict resolution without understanding its limitations. For example, a last-writer-wins policy may lose data silently, and a custom merge function may produce incorrect results in edge cases. Teams that discover these issues in production often revert to manual conflict resolution, which defeats the purpose of the Optimistic Merger.

Eventual Convergence Engine: The Complexity Trap

Eventual Convergence Engines are attractive because they promise conflict-free operation, but they introduce complexity in data structure design and debugging. A common anti-pattern is to implement a custom CRDT without proving its convergence properties, leading to subtle bugs that only surface under specific interleavings. Another anti-pattern is to use CRDTs for data that requires strong invariants—for example, a bank account balance where the total must never exceed the sum of deposits. CRDTs can model this, but the invariants must be encoded in the data type, which is non-trivial.

Teams often revert from CRDTs to a simpler architecture after spending weeks debugging convergence issues. The lesson is that CRDTs are not a free lunch—they require careful design and testing, and they are best suited for data that naturally commutes.

5. Maintenance, Drift, and Long-Term Costs

Choosing an architecture is not a one-time decision—it creates ongoing maintenance costs that evolve as the system grows. Here are the long-term costs we see most often.

Lock-Step Sequencer: Coordination Overhead

The sequencer itself is usually simple, but the surrounding infrastructure—leader election, replication, failure detection—adds significant operational complexity. Teams must handle network partitions, clock skew, and the risk of split-brain scenarios. Over time, the cost of maintaining this infrastructure can exceed the cost of the conflicts it prevents. We've seen teams with small deployments spend more time on consensus protocol tuning than on application logic.

Optimistic Merger: Merge Algorithm Drift

As the data model evolves, the merge algorithm must evolve with it. Adding a new field or changing the semantics of an existing one often requires updating the merge logic, which is error-prone. Over time, the merge code becomes a tangled web of special cases and legacy behaviors. Teams that do not invest in automated testing for merge scenarios often find that subtle bugs creep in, causing data loss or inconsistency. The long-term cost is not just maintenance time but also the cognitive load on developers who must understand the merge algorithm to make changes.

Eventual Convergence Engine: Debugging and Observability

Eventual Convergence systems are notoriously hard to debug because the state is distributed and the convergence is guaranteed only after all updates are propagated. When something goes wrong—for example, two replicas show different values after a network partition—it is difficult to trace the cause. Teams often need to build custom tooling to inspect replica state and simulate network conditions. The long-term cost is higher operational overhead and longer time to resolution for incidents.

Another cost is storage: state-based CRDTs often require storing metadata (like version vectors) alongside each value, which can bloat storage over time. Teams that do not plan for this may face unexpected storage costs or performance degradation.

6. When Not to Use This Approach

Each architecture has scenarios where it is a poor fit. Knowing these can save you from a costly migration.

Avoid Lock-Step Sequencer When:

• You have high write throughput (thousands of writes per second) and cannot afford the latency of consensus.
• Your writers are geographically distributed and network latency is high—the sequencer becomes a bottleneck.
• You need to support offline writes—the sequencer requires a connection to assign sequence numbers.
• Your data can tolerate eventual consistency—the overhead of strong consistency is wasted.

Avoid Optimistic Merger When:

• Your conflict rate is high (e.g., many users editing the same data concurrently).
• You cannot afford to lose data or have users manually resolve conflicts—the merge algorithm's limitations become a liability.
• Your data model is complex and changes frequently—the merge logic will be a constant maintenance burden.
• You need to guarantee that certain invariants hold (e.g., a counter never goes negative)—the merge algorithm may not preserve them.

Avoid Eventual Convergence Engine When:

• Your data requires strong invariants that depend on event order (e.g., a sequence of operations that must be applied in order).
• You have a small team with limited experience in distributed systems—the learning curve is steep.
• You need to debug issues quickly—the lack of observability will slow you down.
• Your data model is deeply nested or has many interdependent fields—designing commutative operations for such structures is extremely difficult.

7. Open Questions and FAQ

Can we mix architectures in the same system?

Yes, and this is often the best approach. For example, you might use a Lock-Step Sequencer for critical metadata (like user permissions) and an Optimistic Merger for collaborative content. The key is to clearly define the boundaries and ensure that cross-architecture interactions are handled correctly—for instance, a user's permission change (sequenced) might affect their ability to edit a document (optimistic). This requires careful design but can give you the best of both worlds.

How do we measure conflict rate?

Conflict rate is the number of conflicting operations divided by the total number of operations over a time window. You can measure it by logging conflicts as they occur (in an Optimistic Merger) or by simulating concurrent writes in a test environment. A conflict rate above 1% is often a warning sign that the architecture may not be suitable.

What is the cheapest architecture to start with?

For most teams, an Optimistic Merger (like a simple merge algorithm or OT) is the cheapest to prototype because it does not require distributed consensus or complex data types. However, the cost of migrating away from it later can be high, so it is worth evaluating your expected conflict rate before committing.

Do CRDTs eliminate all conflicts?

No—CRDTs eliminate the need for conflict resolution by ensuring that concurrent operations commute, but they do not eliminate the semantic conflicts that arise when two users make contradictory changes (e.g., one user deletes a paragraph while another edits it). The CRDT will converge to a state that includes both changes, but that state may not make sense to the users. Semantic conflicts still require application-level handling.

8. Summary and Next Experiments

Choosing a resolution architecture is about matching the dance speed to your constraints. Lock-Step Sequencers are reliable but slow; Optimistic Mergers are fast but fragile under contention; Eventual Convergence Engines are resilient but complex. No single architecture is best for all scenarios.

Here are three next steps you can take:

1. Profile your workload. Measure your write throughput, conflict rate, and latency requirements. Use these numbers to narrow down the candidate architectures.
2. Build a small prototype of the top two architectures with a simplified data model. Run it under simulated load to see how it behaves. Pay attention to debugging difficulty and operational overhead, not just performance.
3. Plan for evolution. Design your system so that you can swap out the resolution architecture if needed. For example, abstract the conflict resolution logic behind an interface, or use an event store that supports multiple ordering strategies.

The timeline tango is not a one-time choice—it's a dance that evolves as your system grows. Start with a clear understanding of your constraints, and you'll find the rhythm that works for you.