Wawancara System Design: Mendesain Editor Kolaboratif Real-Time

Masalah dan Skenario yang Berlaku

Rancang editor kolaboratif real-time yang mendukung paragraf, heading, daftar (list), teks tebal, dan anchor komentar. Sistem ini memiliki 20 juta pengguna aktif harian dan mempertahankan 2 juta koneksi pada puncaknya, dengan 200.000 pengguna aktif mengetik. Seorang editor aktif menghasilkan rata-rata dua pembaruan per detik, dan satu dokumen yang sangat aktif (hot document) dapat memiliki 100 editor bersamaan. Kolaborator online harus melihat pembaruan jarak jauh dalam waktu 200 milidetik pada p95. Pengguna dapat mengedit secara offline hingga 24 jam dan menggabungkannya setelah terhubung kembali. Pembaruan yang telah diakui (acknowledged) oleh server tidak boleh hilang. Kursor, seleksi, dan status online boleh hilang sesaat.

Sistem ini juga mendukung izin viewer, commenter, dan editor, perubahan izin, riwayat versi, undo per pengguna, dan akses multi-wilayah. Wawancara ini tidak mengharuskan pembuktian algoritma CRDT atau OT dari awal atau mereproduksi arsitektur privat perusahaan mana pun. Kandidat harus memilih model resolusi konflik, menghubungkannya ke struktur data editor, transport, persistensi, dan batas otorisasi, serta menyatakan apa yang tidak dapat dijamin oleh desain tersebut.

Materi wawancara bahasa Inggris dan Mandarin saat ini dari tahun 2026 menyajikan pengeditan kolaboratif sebagai masalah desain sistem yang mencakup OT versus CRDT, koneksi WebSocket, document room, presence kursor, pengeditan offline, pembaruan tahan lama, dan pemulihan snapshot. Dokumentasi Yjs memberikan bukti utama untuk pembaruan komutatif, asosiatif, dan idempoten, sinkronisasi delta state-vector, dan awareness non-persisten. Kombinasi tersebut membuat topik ini representatif dan dapat diverifikasi secara teknis.

Apa yang Dinilai oleh Pewawancara

Pertama, apakah kandidat menyelesaikan konvergensi konkuren dan tidak hanya berhenti pada "gunakan WebSocket"? WebSocket menyediakan saluran dua arah (bidirectional). WebSocket tidak menentukan hasilnya ketika dua pengguna menyisipkan teks pada posisi yang sama. Jawaban yang kuat membandingkan model OT yang dimediasi server dengan model CRDT dan memilih salah satu untuk batasan yang ditentukan.

Kedua, apakah jawabannya memisahkan pengalaman lokal dari jaminan durabilitas server? Pengetikan harus diterapkan secara lokal sebelum round trip jaringan. "Diakui berarti tidak hilang" mengharuskan server mereplikasi pembaruan secara tahan lama (durable) di seluruh availability zone sebelum mengembalikan ack. Hingga saat itu, klien menyimpan pembaruan dalam antrean tertunda (pending queue) dan mencoba lagi dengan identitas operasi yang sama.

Ketiga, apakah desain memisahkan konten tahan lama dari presence yang bersifat efemeral? Konten dokumen, anchor komentar, dan riwayat versi harus dapat dipulihkan. Pergerakan kursor memiliki churn tinggi dan kedaluwarsa setelah pemutusan koneksi. Menyimpan setiap pergerakan kursor dalam log dokumen meningkatkan biaya dan mengotori pemulihan dengan state yang basi (stale).

Keempat, dapatkah kandidat bernalar tentang semantik rich-text? Urutan karakter yang konvergen tidak secara otomatis membuat pohon dokumen (document tree) valid. Daftar, tabel, anchor komentar, peningkatan skema, dan cakupan undo memerlukan model, versi, dan invarian yang eksplisit. Offset integer biasa juga bergeser segera setelah pengguna jarak jauh menyisipkan karakter sebelum posisi tersebut.

Akhirnya, apakah kapasitas, hotspot, kepemilikan multi-wilayah, izin, dan verifikasi membentuk loop tertutup? Jawaban yang kuat menghitung beban tulis dan fan-out per ruang, membatasi klien yang lambat, menjelaskan mengapa pengeditan offline yang izinnya telah dicabut tidak dapat langsung digabungkan, dan menggunakan pembaruan yang diurutkan ulang, duplikat, partisi, dan failover untuk membuktikan konvergensi dan durabilitas.

Pertanyaan Klarifikasi Sebelum Menjawab

• Apa yang sedang diedit? Desain utama menggunakan pohon rich-text terstruktur. Byte gambar berada di penyimpanan objek; dokumen berisi referensi dan atribut.
• Apa arti produk dari sebuah konflik? Pembaruan konkuren berkonvergen secara deterministik tanpa saling menimpa. Sistem tidak menyimpulkan maksud bisnis dari dua kalimat yang bertentangan.
• Apa arti diakui (acknowledged)? Server hanya mengirimkan ack setelah pembaruan masuk ke log tahan lama yang direplikasi di tiga availability zone di wilayah asal (home region).
• Apakah diperlukan urutan linier global? Tidak. Konten berkonvergen melalui CRDT. Offset log ada untuk audit, pemulihan, dan batas pengakuan (watermark acknowledgement), bukan untuk kebenaran penggabungan (merge correctness).
• Berapa lama klien boleh tetap offline? Hingga 24 jam. Klien mempertahankan state CRDT lokal dan pembaruan yang belum diakui, kemudian melakukan otorisasi ulang sebelum bertukar delta.
• Apa saja tingkat izinnya? viewer membaca, commenter hanya mengubah domain komentar, dan editor mengubah konten. Bergabung, menyambung kembali, dan setiap penulisan diotorisasi.
• Apakah state kursor bersifat tahan lama? Tidak. Presence menggunakan heartbeat dan TTL. Pembaruan kursor yang hilang digantikan oleh pembaruan state berikutnya.
• Bolehkah beberapa wilayah menerima penulisan untuk dokumen yang sama? Desain utama menetapkan wilayah asal untuk setiap dokumen dan meneruskan penulisan ke sana, menyederhanakan otorisasi, audit, dan failover.
• Berapa lama riwayat versi disimpan? Asumsikan versi yang terlihat oleh pengguna disimpan selama 30 hari. Versi ini berbeda dari snapshot terkompresi/terpadatkan (compacted) yang digunakan untuk sinkronisasi online.
• Apakah enkripsi end-to-end termasuk dalam cakupan? Desain utama memungkinkan server memvalidasi izin dan skema konten. Enkripsi end-to-end adalah trade-off lanjutan.

Kerangka Jawaban 30 Detik

"Saya akan menggunakan CRDT yang direlai server: terapkan pengeditan secara lokal, otorisasi ulang setiap pembaruan WebSocket, berikan ack hanya setelah persistensi tahan lama lintas-zona berhasil, lalu siarkan berdasarkan ruang dokumen (document room). Penyambungan kembali menggunakan state vector untuk perbedaan yang hilang atau memuat snapshot; konten tahan lama dan presence berbasis TTL tetap terpisah. Beban puncak adalah 400.000 pembaruan atau sekitar 120 MB/s. Ruang aktif dengan 100 editor menghasilkan sekitar 19.800 pengiriman jarak jauh per detik, sehingga gateway melakukan batching pembaruan dan membatasi buffer klien yang lambat. Saya akan menguji pembaruan yang diurutkan ulang dan duplikat, penyambungan kembali offline 24 jam, pencabutan izin, dan failover wilayah asal untuk memastikan konvergensi dan durabilitas."

Pembahasan Mendalam Langkah demi Langkah

Mulailah dengan tujuh invarian:

1. Input lokal tidak pernah menunggu jaringan, dan replika yang menerima semua pembaruan berkonvergen ke dokumen valid yang sama.
2. Server mengakui pembaruan konten hanya setelah persistensi tahan lama lintas-zona berhasil.
3. Percobaan ulang (retry), siaran duplikat, dan pengiriman yang urutannya berubah tidak boleh menerapkan pengeditan dua kali atau mengubah hasil akhir.
4. Identitas dan izin saat ini berasal dari sesi server, tidak pernah dari peran di dalam payload pembaruan.
5. Konten, komentar, dan riwayat versi dapat dipulihkan; kursor dan status online dapat kedaluwarsa.
6. Klien yang tidak kompatibel dengan skema tidak dapat terus menulis struktur yang tidak dikenal.
7. Setiap drop, penolakan, degradasi, dan hasil pemulihan dapat diobservasi.

Langkah satu: memilih antara OT dan CRDT.

OT biasanya menggunakan versi server yang terurut sebagai konteks dan mentransformasikan setiap operasi yang masuk terhadap operasi yang konkuren. Pendekatan ini cocok untuk sistem server-otoritatif dengan mesin transformasi yang sudah mapan, tetapi fungsi transformasi, riwayat yang disimpan, dan rebasing offline semuanya harus benar. CRDT mengodekan konkurensi di dalam struktur data. Pembaruan dapat tiba dalam urutan yang berbeda dan lebih dari sekali, dan replika berkonvergen setelah menerima semuanya. Biayanya adalah metadata kausal, deletion marker, binding rich-text yang kompleks, dan penanganan terpisah untuk otorisasi serta konflik semantik.

Karena kebutuhan menuntut pengeditan offline 24 jam dan akses multi-wilayah, desain utama memilih CRDT sequence/tree yang matang dengan relay server dan persistensi tahan lama. CRDT tidak memerlukan deployment terdesentralisasi dan tidak menghilangkan server. Server tetap memiliki kontrol atas identitas, validasi skema, batas ukuran, pengakuan tahan lama, riwayat, kepatuhan, dan fan-out ruang.

Langkah dua: menentukan dokumen terstruktur dan kontrak pesan.

Root dokumen berisi blok-blok dengan ID yang stabil. Paragraf, heading, dan item daftar memiliki teks CRDT dan atribut pemformatan. Thread komentar berada di domain terpisah dan di-anchor ke rentang teks dengan posisi relatif. Versi skema menentukan node, atribut, dan aturan migrasi yang diizinkan. Offset integer tidak stabil: penyisipan sebelum offset tersebut mengubah apa yang ditunjuknya. Posisi relatif menempel pada elemen CRDT dan diselesaikan secara konsisten setelah replika berkonvergen.

Subprotokol WebSocket dapat menggunakan pesan aplikasi berikut:

join {
  documentId, sessionId, schemaVersion, stateVector
}

update {
  documentId, clientId, clientSeq, schemaVersion, payload
}

ack {
  clientId, clientSeq, durableOffset
}

sync {
  payload, durableOffset, schemaVersion
}

presence {
  sessionId, relativeCursor, relativeSelection, statusSeq
}

(documentId, clientId, clientSeq) adalah kunci idempotensi percobaan ulang. durableOffset mendukung pengakuan dan audit tetapi tidak berpartisipasi dalam kebenaran penggabungan CRDT. Pesan memiliki batas ukuran terkompresi dan tidak terkompresi ditambah daftar izin skema. Node yang tidak dikenal atau perubahan domain yang tidak diotorisasi ditolak secara eksplisit alih-alih disiarkan.

Langkah tiga: memisahkan jalur pemuatan, live room, dan penyimpanan.

Client
  -> HTTPS snapshot service -> metadata + snapshot store
  -> WebSocket gateway -> document room router -> collaboration service
                                              -> durable update log
                                              -> room pub/sub -> gateways

Client
  -> presence channel -> regional ephemeral store -> room fan-out

Klien pertama-tama memuat metadata dokumen, skema saat ini, dan snapshot terpadatkan terbaru melalui HTTPS, lalu membuka WebSocket. Gateway mengelola koneksi dan langganan ruang tetapi tidak membuat aturan penggabungan. Layanan kolaborasi merutekan berdasarkan dokumen ke wilayah asalnya, mengotorisasi dan memvalidasi setiap pembaruan, menyimpannya, memberikan ack, dan memublikasikannya. Bus ruang memublikasikan sekali ke setiap gateway yang memiliki pelanggan, dan setiap gateway melakukan fan-out secara lokal alih-alih mengirimkan satu pesan lintas-node per penerima.

Langkah empat: jadikan pengeditan lokal, pengakuan, dan percobaan ulang sebagai state machine yang eksplisit.

Pengeditan lokal segera memperbarui tampilan dan masuk ke antrean tertunda (pending queue) yang persisten secara lokal. Saat online, klien dapat menggabungkan (batch) penekanan tombol yang berdekatan dalam jendela 20 hingga 50 milidetik untuk mengurangi jumlah pesan. Waktu tersebut merupakan asumsi input dan harus disesuaikan dengan uji interaksi. Untuk setiap pembaruan, server mengotentikasi sesi, membaca izin saat ini, memvalidasi skema dan batas sumber daya, menambahkannya ke log yang direplikasi, mengembalikan ack, dan menyiarkannya. Hanya ack yang dapat menghapus pembaruan dari antrean tertunda.

Jika koneksi gagal setelah commit tetapi sebelum ack, klien mencoba lagi dengan clientSeq yang sama. Kendala keunikan server dapat mengembalikan pengakuan asli. Idempotensi CRDT juga membuat penerapan berulang menjadi aman, tetapi catatan audit dan penagihan tetap memerlukan deduplikasi. Klien yang lambat menerima send buffer yang dibatasi. Setelah melewati batas atas (high-water mark), gateway membuang presence terlebih dahulu dan kemudian meminta klien untuk melakukan sinkronisasi ulang dari state vector daripada membiarkan satu koneksi menghabiskan memori ruang tanpa batas.

Langkah lima: gunakan state vector untuk sinkronisasi online, offline, dan penyambungan kembali.

Pembaruan CRDT yang komutatif, asosiatif, dan idempoten memungkinkan replika menerima pembaruan dalam urutan berbeda dan mencoba lagi dengan aman. Saat menyambung kembali, klien mengirimkan state vector yang mendeskripsikan state kausal yang sudah dimilikinya, dan server menghitung perbedaan yang hilang. Jika delta terlalu besar, skema berubah, atau jendela riwayat online telah kedaluwarsa, server mengirimkan snapshot CRDT lengkap saat ini dan kemudian menerapkan pembaruan lokal yang masih diotorisasi.

Urutannya adalah otentikasi, otorisasi, negosiasi skema, lalu pertukaran konten. Jika izin mengedit dicabut saat pengguna sedang offline, konvergensi bukanlah izin untuk menerima perubahan. Server mengembalikan error permission_revoked yang stabil dan menyediakan jalur pemulihan lokal untuk ekspor atau penyalinan, tetapi tidak menulis draf tersebut ke dokumen bersama. Produk mengorbankan "setiap pengeditan offline harus digabungkan" demi mempertahankan kontrol akses saat ini.

Langkah enam: merancang snapshot, riwayat versi, dan pemadatan (compaction).

Log tahan lama dipartisi berdasarkan documentId dan mencatat ID pembaruan, penulis, skema, payload, waktu terima, dan offset tahan lama. Pemadat latar belakang (background compactor) memuat state CRDT, menggabungkan inkremen menjadi snapshot yang dapat dimuat secara langsung, dan mencatat offset yang dicakup. Pemadat menghapus inkremen lama hanya setelah snapshot baru lolos validasi, tersimpan secara tahan lama di penyimpanan objek, dan mempertahankan titik rollback untuk jendela pemulihan dan audit.

Menggabungkan pembaruan biner menghapus informasi duplikat tetapi tidak secara otomatis melakukan garbage collection terhadap konten yang dihapus. Deletion marker, sinkronisasi offline, anchor komentar, undo per pengguna, dan versi historis saling berinteraksi. Oleh karena itu, pemadatan memerlukan pengujian dokumen nyata. Riwayat yang terlihat oleh pengguna menyimpan snapshot bernama independen atau indeks perubahan; pemadatan sinkronisasi online bukanlah pengganti riwayat versi produk.

Langkah tujuh: memisahkan presence dan mengontrol fan-out hotspot.

Presence berisi sesi, nama tampilan, warna, kursor relatif, seleksi, dan statusSeq monotonik, yang diperbarui melalui heartbeat dan TTL. Presence tidak pernah masuk ke dalam CRDT dokumen atau log tahan lama. Penerima membuang nomor urut yang lebih lama, dan state pemutusan koneksi akan kedaluwarsa. Kehilangan satu pembaruan kursor hanya berdampak sementara karena pembaruan berikutnya akan menggantikannya.

Ruang dengan 100 editor pada dua pembaruan per detik menghasilkan 200 pembaruan konten per detik. Mengirimkan setiap pembaruan ke 99 pengguna lainnya berarti sekitar 19.800 pengiriman jarak jauh per detik sebelum menghitung presence. Gateway menggabungkan pembaruan dari irisan waktu yang singkat, memublikasikan berdasarkan ruang dokumen, membatasi frekuensi presence, serta menerapkan batas byte dan pesan per koneksi. Dokumen yang sangat aktif dapat diberikan actor ruang khusus dan partisi pub/sub, tetapi sistem tidak pernah melakukan sampling pada pengeditan konten tahan lama untuk mengurangi beban.

Langkah delapan: menghitung ulang kapasitas global dan sumber daya koneksi.

Dua ratus ribu editor pada dua pembaruan per detik menghasilkan 400.000 pembaruan per detik. Pada payload biner rata-rata 300 byte, penulisan mentah sekitar 120 MB/s atau 10,37 TB/hari. Replikasi, indeks, header, snapshot, dan riwayat versi memerlukan kapasitas tambahan. Jika satu koneksi gateway membutuhkan 50 KiB, 2 juta koneksi memerlukan sekitar 100 GiB state gateway. Pada 20.000 koneksi per gateway, batas dasarnya adalah 100 gateway sebelum memperhitungkan kegagalan dan ruang deployment (headroom).

Estimasi ini adalah titik awal. Egress ruang aktif, CPU untuk TLS dan encoding, buffer klien yang lambat, dan partisi log tahan lama dapat menjadi bottleneck sebelum penyimpanan konten mentah. Pantau tingkat pembaruan dan fan-out berdasarkan dokumen dan tenant, latensi ack, ukuran delta state-vector, penyambungan kembali, watermark buffer, usia snapshot, dan kegagalan pemeriksaan konvergensi.

Langkah sembilan: membatasi perilaku multi-wilayah, failover, dan keamanan.

Metadata dokumen mencatat wilayah asal dan epoch yang meningkat. Klien masuk melalui gateway terdekat, sementara penulisan konten dirutekan ke wilayah asal. Penerapan lokal instan menyembunyikan RTT lintas wilayah dari pengetikan. Jika wilayah asal gagal, control plane terlebih dahulu menaikkan epoch, kemudian wilayah baru memulihkan dari log yang direplikasi dan snapshot terbaru. Lapisan persistensi menolak epoch actor lama sehingga dua pemilik ruang tidak dapat sama-sama menerbitkan pengakuan tahan lama.

Konvergensi CRDT tidak menggantikan satu pun keputusan otorisasi, pengakuan tahan lama, atau pembatasan (fencing) failover. Keamanan juga memerlukan batasan dokumen, pembaruan, laju (rate), dan rasio dekompresi; pemeriksaan otorisasi Origin, sesi, dan dokumen; enkripsi dalam transit dan at-rest; audit untuk pembagian, perubahan izin, dan ekspor; serta log yang tidak memuat token akses, isi dokumen, dan detail kursor yang presisi.

Langkah sepuluh: membuktikan desain dengan property test dan fault injection.

Hasilkan pembaruan dari beberapa klien pada dokumen awal yang sama. Terapkan dalam urutan acak, dengan duplikat, penundaan, dan batch. Setiap replika harus berakhir dengan hasil serialisasi yang sama dan skema yang valid. Tambahkan penyisipan pada posisi yang sama, penghapusan yang tumpang tindih, menghapus parent saat mengedit child-nya, pemformatan dan teks yang bersamaan, anchor komentar, undo per pengguna, dan peningkatan skema.

Matikan layanan kolaborasi setelah penambahan tahan lama (durable append) tetapi sebelum ack; percobaan ulang harus menghasilkan satu pembaruan yang diaudit. Matikan layanan setelah ack tetapi sebelum siaran; pemulihan harus mengirimkan pembaruan tersebut. Sambungkan kembali setelah 24 jam offline dan uji jalur delta state-vector serta snapshot. Cabut izin sebelum mengirimkan pembaruan offline; persistensi bersama harus menolaknya sambil mempertahankan pemulihan lokal. Terakhir, lakukan uji beban pada ruang aktif 100 editor dengan konten dan presence, memverifikasi latensi p95, batas memori, dan urutan degradasi yang diinginkan.

Contoh Jawaban Berkualitas Tinggi

"Saya akan mulai dengan tiga kontrak: input lokal diterapkan segera; replika yang menerima semua pembaruan akan berkonvergen; dan hanya pembaruan yang dicatat secara tahan lama di tiga availability zone yang diakui. Persyaratan offline 24 jam mendukung penggunaan CRDT terstruktur yang matang, sementara server tetap memegang otoritas untuk otentikasi, skema, persistensi, dan fan-out.

Setelah memuat snapshot CRDT, klien bergabung dengan ruang dokumen. Pengeditan lokal diterapkan terlebih dahulu dan masuk ke antrean tertunda di bawah clientId + clientSeq, lalu dikirim melalui WebSocket sebagai pembaruan biner. Layanan kolaborasi memeriksa ulang izin saat ini, skema, dan batas sumber daya, menambahkan pembaruan secara tahan lama, memberikan ack, dan memublikasikannya ke ruang. Percobaan ulang mempertahankan urutan yang sama. Pembaruan mentolerir perubahan urutan dan duplikasi. Saat menyambung kembali, klien mengirimkan state vector dan menerima perubahan yang hilang atau snapshot penuh. Jika izin dicabut saat offline, penulisan bersama ditolak dan hanya ekspor lokal yang tetap tersedia.

Konten dan presence menggunakan jalur terpisah. Kursor menggunakan posisi relatif, sementara presence berbasis TTL tidak dicatat secara tahan lama. Setiap dokumen memiliki wilayah asal dan epoch. Failover menaikkan epoch sebelum memulihkan dari log dan snapshot yang direplikasi, sehingga pemilik ruang yang lama tidak dapat terus mengakui pembaruan.

Pada puncaknya, 200.000 editor dikalikan dua pembaruan per detik sama dengan 400.000 pembaruan per detik. Pada 300 byte, itu berarti 120 MB/s dan 10,37 TB/hari pembaruan mentah. Dokumen aktif dengan 100 editor menghasilkan sekitar 200 pembaruan dan 19.800 pengiriman jarak jauh per detik, sehingga bus ruang memublikasikan sekali, gateway melakukan batching dan fan-out secara lokal, dan buffer klien yang lambat dibatasi. Saya akan membuktikan sistem ini dengan mengacak urutan dan menduplikasi pembaruan hingga setiap replika berkonvergen, lalu menyuntikkan crash di sekitar batas ack, penyambungan kembali offline 24 jam, pencabutan izin, peningkatan skema, dan kegagalan wilayah asal."

Kesalahan Umum

• Hanya mengatakan "gunakan WebSocket" → Transport tidak menyelesaikan pengeditan konkuren → Pilih OT atau CRDT dan jelaskan konvergensi serta biayanya.
• Menyimpan seluruh dokumen untuk setiap pengeditan → Pengguna konkuren saling menimpa dan bandwidth membengkak seiring ukuran dokumen → Kirim pembaruan inkremental yang dapat digabungkan.
• Memberikan ack setelah penerimaan di memori → Crash pada proses menghilangkan pekerjaan yang telah diakui → Berikan ack setelah penambahan tahan lama lintas-zona.
• Menganggap CRDT sebagai otorisasi → Konvergensi matematis tidak menghentikan pengguna yang izinnya telah dicabut → Otorisasi proses bergabung, penyambungan kembali, dan setiap penulisan.
• Menyimpan kursor sebagai offset integer → Penyisipan konkuren menggeser posisi yang dimaksud → Gunakan posisi relatif terhadap elemen CRDT.
• Menyimpan pergerakan kursor dalam log konten → State efemeral dengan churn tinggi membuat penyimpanan dan pemulihan membengkak → Gunakan saluran presence berbasis TTL.
• Mengklaim pengiriman exactly-once → Penyambungan kembali dan siaran dapat terduplikasi → Gunakan pembaruan idempoten, identitas unik, dan state yang dapat diputar ulang (replayable).
• Menghapus semua riwayat segera setelah snapshot → Sinkronisasi offline, rollback, undo, atau migrasi skema dapat kehilangan konteks yang diperlukan → Kumpulkan (garbage collect) hanya di luar batas pemulihan yang telah divalidasi.
• Hanya menghitung ingress konten → Fan-out ruang aktif dan klien yang lambat sering kali menghabiskan sumber daya terlebih dahulu → Hitung juga pengiriman, egress, dan buffer.
• Menerima penulisan aktif di mana saja tanpa control plane → Kepemilikan otorisasi, ack, dan failover menjadi ambigu → Gunakan wilayah asal dan epoch.

Pertanyaan Lanjutan dan Jawaban

Pertanyaan lanjutan satu: Mengapa memilih CRDT daripada OT?

Persyaratan offline 24 jam serta transport multi-wilayah yang rentan duplikasi dan perubahan urutan sangat cocok dengan model pembaruan CRDT, dan implementasi yang matang dapat bertukar perbedaan menggunakan state vector. OT tetap valid. Dengan mesin transformasi server yang terbukti, satu layanan pengeditan terurut, dan perilaku offline yang terbatas, OT dapat memberikan metadata dan semantik server yang lebih terkontrol. Keputusan ini didasarkan pada batasan produk dan kemampuan tim, bukan karena menyatakan satu akronim secara universal lebih baru.

Pertanyaan lanjutan dua: Apakah CRDT menghilangkan kebutuhan akan log pembaruan tahan lama?

Tidak. CRDT menyelesaikan penggabungan dan konvergensi. Durabilitas yang diakui, audit, riwayat, pemulihan, dan pemuatan perangkat baru tetap memerlukan state yang tahan lama. Sistem dapat memadatkan inkremen menjadi snapshot dan mengumpulkan entri log lama setelah jendela pemulihan, tetapi sistem harus mempertahankan batas durabilitas dan titik rollback yang dapat diverifikasi.

Pertanyaan lanjutan tiga: Bagaimana jika izin pengguna offline telah dicabut?

Otentikasi dan otorisasi ulang sebelum bertukar konten. Tolak penulisan bersama dengan error yang stabil dan simpan salinan lokal untuk diekspor atau disalin; jangan membuangnya secara diam-diam. Bisnis mungkin mengizinkan administrator meninjau draf tersebut di area persetujuan terisolasi, tetapi jalur tersebut tidak boleh melewati ACL dokumen saat ini.

Pertanyaan lanjutan empat: Bagaimana cara kerja undo dengan banyak pengguna?

Secara default, batalkan operasi lokal terbaru dari pengguna saat ini dan gabungkan operasi inversi tersebut melalui CRDT. Memulihkan seluruh snapshot lama akan menghapus pekerjaan pengguna lain setelahnya. Catat pengguna dan batas transaksi untuk setiap operasi, simpan konten yang dihapus untuk jendela undo yang ditargetkan, dan tentukan semantik reversibel dalam editor binding untuk perubahan struktural.

Pertanyaan lanjutan lima: Bagaimana kursor menghindari pergeseran melompat setelah pengeditan konkuren?

Simpan anchor kursor dan komentar relatif terhadap elemen CRDT daripada offset karakter absolut. Selesaikan posisi relatif ke indeks saat ini setelah menerapkan pembaruan jarak jauh. Jika anchor dan struktur parent telah dihapus, sembunyikan kursor, tandai komentar sebagai terlepas (detached), atau alihkan ke blok valid terdekat sesuai dengan aturan produk yang eksplisit.

Pertanyaan lanjutan enam: Bagaimana jika sepuluh ribu orang membuka satu dokumen?

Pisahkan editor dari viewer read-only. Publikasikan setiap pembaruan konten sekali di bus ruang dan lakukan fan-out dari gateway. Klien read-only dapat menerima pembaruan yang digabungkan pada frekuensi yang lebih rendah atau melakukan polling pada snapshot berumur pendek tanpa mengubah kebenaran editor. Presence hanya menampilkan peserta yang terlihat atau yang disampling, dan setiap koneksi memiliki send buffer yang dibatasi. Menampilkan seluruh sepuluh ribu kursor akan memerlukan anggaran bandwidth dan UI tersendiri.

Pertanyaan lanjutan tujuh: Bisakah editor mendukung enkripsi end-to-end?

Klien dapat mengenkripsi pembaruan CRDT sementara server merelai dan menyimpan ciphertext. Trade-off-nya adalah server tidak lagi dapat memvalidasi skema rich-text, mencari konten, melakukan moderasi, melakukan ekspor terperinci, atau memulihkan data yang hilang dengan mudah. Rotasi kunci, penghapusan anggota, dan pembaruan offline anggota lama juga menjadi lebih sulit. Tentukan model ancaman serta protokol kunci dokumen, perangkat, dan keanggotaan terlebih dahulu; TLS pada WebSocket saja hanyalah enkripsi transport, bukan enkripsi end-to-end.

Pertanyaan lanjutan delapan: Bagaimana cara mendeteksi silent replica fork?

Setelah periode hening atau penyambungan kembali, klien melaporkan state vector dan digest state yang tidak sensitif. Bandingkan hanya replika pada watermark tahan lama yang sama; ketidakcocokan akan memicu sinkronisasi ulang penuh dan menyimpan sampel diagnostik. Dokumen canary berkelanjutan menerbitkan pembaruan konkuren yang diketahui dari beberapa wilayah dan memverifikasi digest akhir, skema, jumlah ack, dan watermark log. Membandingkan digest pada watermark in-flight yang berbeda akan menimbulkan alarm palsu (false alarm).