Design Google Calendar

Prompt latihan

1. Problem Statement, Functional Requirements, and Scale Assumptions

   Tentukan ruang lingkup produk Google Calendar: membuat dan mengedit event, event berulang, undangan dan RSVP, serta pengingat. Kecualikan secara eksplisit integrasi video conferencing, pemesanan ruangan dan sumber daya, serta integrasi email dari desain awal. Nyatakan asumsi skala awal sebelum mengusulkan komponen apa pun.

2. Non-Functional Requirements

   Tentukan NFR utama: ketersediaan tampilan kalender yang read-heavy, latensi rendah untuk operasi CRUD event, konsistensi kuat untuk pembuatan event guna mencegah double-booking, kebenaran timezone lintas region, dan fanout undangan yang skalabel untuk kalender bersama berukuran besar. Putuskan jalur mana yang kritis-latensi versus mana yang dapat mentoleransi eventual consistency.

3. Quantitative Analysis

   Estimasikan QPS tampilan kalender (tampilan hari/minggu/bulan per pengguna per hari), QPS pembuatan dan pembaruan event, faktor ekspansi event berulang (ekspansi RRULE untuk 30 hari ke depan), storage per event (metadata plus daftar undangan), dan tulisan fanout undangan untuk kalender bersama besar. Turunkan rasio read-to-write dan implikasinya terhadap storage dan caching.

4. API Design

   Tentukan operasi API untuk membuat event, memperbarui event (satu instance atau seluruh series), menghapus event (satu instance atau series), mengambil tampilan kalender untuk rentang tanggal (hari/minggu/bulan), membuat event berulang dengan RRULE, dan merespons undangan (RSVP: accept/decline/maybe). Sertakan bentuk request dan response, bagaimana modifikasi series event berulang dicakup (ini, ini-dan-berikutnya, semua), dan penanganan timezone dalam parameter request.

5. High-Level Design

   Usulkan komponen utama: calendar service, event store, recurring event engine, notification service, invitation service, dan lapisan konversi timezone. Jelaskan tanggung jawabnya, alur data untuk membuat event (simpan, ekspansi instance berulang, fanout undangan, jadwalkan pengingat), dan jalur panas tampilan kalender (ambil event dalam rentang tanggal, ekspansi series berulang secara virtual, render dalam timezone pengguna).

6. Additional High-Level Design Prompts

   Perjelas model berbagi dan izin kalender Anda (peran owner, editor, viewer, berbagi dengan pengguna eksternal), bagaimana overlay kalender bekerja (merender beberapa kalender dalam satu tampilan), dan apakah pencarian event masuk MVP atau merupakan perhatian yang ditangguhkan. Bahas juga bagaimana model data menangani respons undangan (state RSVP per-undangan) tanpa menggandengkan record event inti dengan fanout undangan.

7. Deep Dives

   Deep dive ke tiga area: (1) Ekspansi event berulang, bandingkan virtual instance (ekspansi RRULE saat baca dari satu baris base event) versus materialized instance (pra-generasi semua instance masa depan dan simpan sebagai baris); bahas kompleksitas parsing RRULE (FREQ, INTERVAL, BYDAY, COUNT, UNTIL), penanganan pengecualian (instance individual yang dimodifikasi atau dibatalkan disimpan sebagai baris override), dan paginasi event yang diekspansi dalam query rentang tanggal; (2) Penanganan timezone, jelaskan mengapa semua datetime disimpan dalam UTC dengan identifier timezone terpisah; telusuri edge case transisi DST (jam yang dilewati saat spring-forward, jam yang berulang saat fall-back); rancang rendering undangan lintas-timezone (setiap attendee melihat event dalam timezone lokalnya sendiri); bahas update versi database timezone (IANA tz) dan dampaknya; (3) Deteksi konflik, rancang API query busy/free yang memeriksa rentang event yang tumpang tindih di beberapa kalender secara efisien; jelaskan strategi locking atau optimistic concurrency untuk mencegah double-booking pada pembuatan event bersamaan untuk slot waktu yang sama.

8. Final Review Handoff Readiness

   Ringkas keputusan desain end-to-end: model storage event berulang yang dipilih (virtual vs. materialized), pendekatan storage timezone, strategi deteksi konflik, model fanout undangan, dan model data untuk state RSVP per-undangan. Soroti dua risiko terbesar yang tersisa (edge case transisi DST dan konflik booking bersamaan), dan berikan rencana rollout dengan feature flag untuk mengaktifkan ekspansi event berulang dan akses kalender bersama secara bertahap.

Preview solusi

Jalur referensi Solusi Google Calendar adalah materi belajar yang bersifat read-only. Gunakan untuk membandingkan desain Anda sendiri dengan sebuah jalur referensi yang ringkas sebelum memulai latihan atau setelah Anda menyelesaikan satu putaran. Simpan semua datetime event dalam UTC dengan identifier timezone IANA yang terpisah; jangan pernah menyimpan wakt…