Aamu uses ShareDB and Operational Transformation (OT) for collaborative editing, with the server validating and ordering accepted changes.

CRDTs let replicas merge concurrent changes and are useful for local-first and offline collaboration. They can also be deployed with a central server.

Clients edit optimistically. ShareDB transforms concurrent operations, and the server stores and broadcasts the accepted state.

Documents live next to tasks, email, helpdesk, meetings, databases, forms, files, comments, permissions, automations, search, AI features, and team-level workflows. In that kind of product, the hardest problem is not only merging text edits. The harder problem is keeping the whole workspace consistent.

The core tradeoff

They are designed for situations where different users, devices, or replicas may edit the same data independently and later synchronize their changes. In an ideal CRDT-based system, users can keep working even without a stable connection, and the system can merge concurrent changes automatically.

But Aamu.app optimizes for a different set of constraints:

  • clear permissions

  • predictable business logic

  • auditability

  • integration with other workspace objects

  • reliable automations

  • consistent search and AI indexing

  • a single source of truth for team data

We chose a central authority to keep these checks and workflows in the existing backend. This deployment choice is separate from whether edits use OT or CRDTs.

A comment might become a task.
A document might be linked to a customer conversation.
A database row might reference a file or a helpdesk ticket.
An AI command might turn text into an action.
A permission change might immediately affect who is allowed to see or edit something.
A search index or Team Brain feature may need to update when content changes.
An automation may need to run exactly once when a specific event happens.

A server-authoritative model gives us a clear place to answer important questions:

  • Is this user still allowed to make this change?

  • What is the canonical order of changes?

  • Which version of the document did this change apply to?

  • What other objects should be updated because of this change?

  • Should an automation run?

  • Should search or AI indexes be refreshed?

  • What should be written to the audit log?

  • What should other users see next?

With ShareDB and OT, the server can decide these things in one controlled flow.

Permissions are simpler with a central authority

Permissions are one of the strongest reasons to prefer a central server in a business workspace.

Imagine a user opens a document, goes offline, and keeps editing for an hour. During that time, an admin removes their access to the workspace, the project, or the document.

What should happen when the user comes back online?

In a CRDT-first architecture, the system may have technically valid changes that can merge cleanly with the document. But from the business point of view, those changes may no longer be allowed.

CRDT-based applications can validate writes on a central server too. The permission boundary comes from the application’s authorization design, not from the merge algorithm.

In a server-authoritative model, the rule is more direct: the server validates every accepted change. If the user no longer has permission, the change is rejected.

Business events need reliable processing

But in Aamu.app, a document edit can also be part of a larger workflow. It might trigger an automation, update an activity feed, create a notification, refresh an AI context, or connect to another object in the workspace.

Ordering edits does not by itself guarantee exactly-once side effects.

Background jobs still need durable state, retry handling and deduplication. A central server gives us one place to coordinate that work.

When the server accepts an operation, it can also decide what else should happen. It can update related records, queue background jobs, send notifications, and record activity in a predictable order.

Auditability matters in team software

Aamu.app is built for teams and businesses. In that context, it is useful to know what happened and when.

A server-authoritative OT model gives us a simple history:

  • operation accepted

  • document version updated

  • user recorded

  • timestamp stored

  • related events triggered

  • other clients notified

CRDT systems can also record authorship and operation history. ShareDB’s ordered document versions fit Aamu’s existing storage and debugging tools.

Offline-first is not our main product promise

Search, permissions, automations, notifications, AI features, integrations, and cross-object workflows all depend on having a reliable shared backend.

We may still support local drafts, temporary offline resilience, and optimistic editing where it makes sense. But full local-first collaboration is not the central design goal.

OT is a good fit for our needs

Operational Transformation has a long history in collaborative editing. The basic idea is that users can make concurrent edits, and the system transforms operations so they can be applied in a consistent order.

ShareDB gives Aamu.app a practical foundation for this model.

With ShareDB, we get:

  • real-time synchronization

  • optimistic local editing

  • server-side ordering of operations

  • a canonical document state

  • integration with our existing backend

  • a clear place for validation and authorization

  • a model that fits well with other server-side business logic

Why not use both?

A product can use CRDTs for some local-first data, OT for document editing, server-side events for business workflows, and traditional database transactions for core records.

Aamu.app already combines many parts of work into one product. Adding a CRDT layer would not only mean changing the editor sync model. It would affect storage, migrations, permissions, version history, indexing, automations, testing, backups, and support.

For Aamu’s current requirements, ShareDB fits the backend we already operate.

The tradeoff we accept

Collaboration depends on the backend being available and responsive. Full offline editing would require additional design work.

Related articles