A write takes a different path back to the applicationThe application sends mutations through its API to Postgres. An API response returns on that path. Separately, committed changes flow from Postgres through a read-path sync engine to the local dataset. Optional optimistic local state must be reconciled with the authoritative result. Other clients also write to the same Postgres database. The animation illustrates a successful commit; a rejected write returns through the API and its pending local change is rolled back. APPLICATION RUNTIME ApplicationSends a mutationEDIT: PRICE → $120 Local datasetCommitted + pending stateReconcile the local view Write APIAuthorize + validateSubmit transaction PostgresAuthoritative stateCOMMIT / ROLLBACKCoordinates all writers Sync engineStreams committedchanges to clients Write request Transaction Write result API response Optimistic stateOptional · pending Logical replication Sync back Other clients The API response and the local synchronized update are separate events.

The application sends mutations through its API to Postgres. An API response returns on that path. Separately, committed changes flow from Postgres through a read-path sync engine to the local dataset. Optional optimistic local state must be reconciled with the authoritative result. Other clients also write to the same Postgres database. The animation illustrates a successful commit; a rejected write returns through the API and its pending local change is rolled back. Animation timing is illustrative, not a latency measurement. The three steps advance automatically; select a tab to jump to that step.