Prompt dan konteks yang sesuai
Ini adalah pertanyaan system design. Inti masalahnya bukan memilih pembuatan versi melalui URL atau header; melainkan mendesain control plane untuk siklus hidup API. Perubahan kontrak harus mengalir ke analisis dampak, penemuan konsumen nyata, pemeriksaan perilaku lama/baru, migrasi bertahap, dan penutupan berbasis bukti. Microsoft merekomendasikan untuk mempertahankan kompatibilitas mundur (backward compatibility) jika memungkinkan, dan Google Cloud juga menyarankan untuk mencoba evolusi yang kompatibel terlebih dahulu. Wawancara ini meminta Anda untuk mengubah prinsip-prinsip tersebut menjadi sistem yang berfungsi di seluruh tim.
Apa yang dinilai oleh pewawancara
- Apakah Anda membedakan antara kompatibilitas format, perubahan semantik entitas, dan perubahan yang benar-benar merusak (breaking changes).
- Apakah Anda menghubungkan kontrak API, inventaris konsumen, traffic runtime, dan pekerjaan migrasi.
- Apakah Anda mendesain pengujian kompatibilitas, peluncuran bertahap, peringatan, pemberitahuan, dan rollback daripada hanya sekadar label versi.
- Apakah Anda dapat menjelaskan biaya operasional dari banyak versi, risiko konversi data, dan batasan organisasi.
Klarifikasi yang perlu ditanyakan terlebih dahulu
Konfirmasikan apakah API bersifat internal, untuk mitra (partner-facing), atau publik; apakah konsumen dapat diidentifikasi sepenuhnya; serta target traffic, latensi, dan ketersediaan. Perjelas apakah field tersebut bersifat opsional, apakah artinya berubah, dan apakah operasi baca (read), tulis (write), atau data persisten terlibat. Tanyakan tentang OpenAPI atau sumber kontrak lainnya, SDK klien, saluran pemberitahuan, jendela dukungan, persyaratan kepatuhan, dan durasi rollback. Jika skala tidak ditentukan, nyatakan asumsi Anda.
Kerangka jawaban 30 detik
Saya akan mendesain lima tahap: registri kontrak, penemuan dampak, validasi kompatibilitas, koordinasi migrasi, dan bukti penghentian. Setiap kontrak API masuk ke registri; rule engine mengklasifikasikan perubahan, lalu menggabungkan dependensi statis dan panggilan runtime untuk mengidentifikasi konsumen. Versi lama dan baru berjalan secara paralel sementara konsumen menerima pemberitahuan disertai batas waktu dan panduan migrasi. Selama peluncuran bertahap, catat keberhasilan, kesalahan, dan sisa traffic berdasarkan versi. Penghentian hanya dilakukan setelah konsumen penting bermigrasi, bukti migrasi lengkap, rollback telah dilatih, dan pemilik (owner) menyetujui perubahan tersebut.
Jawaban mendalam langkah demi langkah
1. Bangun registri kontrak dan aturan perubahan
Registri menyimpan setiap API, versi, pemilik, semantik field, cakupan autentikasi, status dukungan, tanggal depresiasi, dan dokumentasi migrasi. Permintaan perubahan mencakup perbandingan kontrak (diff), dan rule engine menandai field yang dihapus, enum yang dipersempit, perubahan status wajib/opsional, perubahan semantik error, dan perubahan relasi entitas. Menambahkan field yang dapat diabaikan sering kali kompatibel, tetapi klien tidak dapat diasumsikan mengabaikan field yang tidak dikenal dengan benar; tim memerlukan jalur pengecualian yang didukung bukti.
2. Temukan konsumen dan bangun graf dampak
Gabungkan dependensi repositori, log gateway, telemetri service-mesh, pendaftaran SDK, dan deklarasi ke dalam graf API-versi-konsumen. Penemuan statis dapat melewatkan permintaan yang dibuat secara dinamis, sedangkan penemuan runtime dapat melewatkan tugas berkala yang jarang berjalan, jadi tandai sumber bukti, waktu terakhir terlihat, dan tingkat keyakinan. Untuk klien eksternal, simpan hanya pengenal tenant dan aplikasi yang diperlukan daripada memperlakukan log sebagai data pribadi tanpa batas waktu.
3. Validasi kompatibilitas dengan safety gate
Untuk setiap perubahan, jalankan pengujian kontrak, replay konsumen, dan perbandingan sampel traffic. Periksa semantik respons pada operasi baca dan verifikasi bahwa operasi tulis klien lama tidak menghilangkan data atau menimbulkan efek samping yang tidak diinginkan. Mulai perubahan yang merusak pada shadow traffic atau kelompok tenant kecil; perutean versi dan feature flag harus dapat dikembalikan (reversible). Pertahankan versi lama saat terjadi kegagalan daripada menganggap serangkaian pengujian yang lulus sebagai bukti untuk konsumen yang belum diuji.
4. Koordinasikan pemberitahuan, migrasi, dan pengoperasian multi-versi
Layanan pemberitahuan mengirimkan panduan migrasi, batas waktu, contoh permintaan, dan kontak berdasarkan konsumen, tingkat keparahan, dan kontrak dukungan; pelanggan eksternal memerlukan halaman status atau konsol yang dapat ditanyakan. Pekerjaan migrasi mencatat pemilik, pemblokir, bukti validasi, dan panggilan sukses terakhir. Multi-versi menambah biaya pengujian, deployment, dan pemantauan, jadi tetapkan batas jumlah versi, tahapan depresiasi, dan jalur migrasi daripada mendukung setiap versi tanpa batas waktu.
5. Putuskan penghentian, amati, dan pulihkan
Sebelum penghentian, verifikasi bahwa konsumen penting telah meningkatkan versi, sisa panggilan berada di bawah ambang batas, tidak ada regresi error, konversi data dapat dibatalkan, dan kesiapan dukungan terpenuhi. Gunakan kelompok (cohort) dan jendela waktu: hentikan onboarding baru, kembalikan pesan error depresiasi yang jelas dan tautan migrasi ke panggilan lama, lalu nonaktifkan perutean. Lacak kegagalan kompatibilitas, traffic versi lama, penyelesaian migrasi, pengiriman pemberitahuan, jumlah rollback, dan error tersegmentasi konsumen. Kubernetes menunjukkan bagaimana tingkat stabilitas, periode dukungan minimum, konversi, dan batasan rollback dapat menjadi kebijakan eksplisit; konfigurasikan batasan tersebut untuk organisasi daripada menyalin tanggalnya secara mentah-mentah.
Contoh jawaban berkualitas tinggi
Saya akan mengklarifikasi tipe konsumen, sumber kontrak, semantik baca/tulis dari field yang dihapus, kewajiban pemberitahuan eksternal, dan durasi rollback. Registri kontrak memasok rule engine perubahan yang mengidentifikasi perbedaan yang merusak dan menghubungkannya ke graf dampak yang dibangun dari dependensi kode, log gateway, dan telemetri service-mesh, dengan kebaruan bukti. Pengujian kompatibilitas, replay konsumen, dan traffic bertahap memvalidasi perilaku lama dan baru; layanan pemberitahuan mengirimkan panduan migrasi dan batas waktu ke setiap konsumen. Versi berjalan secara paralel, dan pekerjaan migrasi menyimpan bukti validasi. Hanya setelah konsumen penting bermigrasi, sisa traffic dan error memenuhi ambang batas, rollback dilatih, dan pemilik menyetujuinya, kami memensiunkan rute lama. Log audit mencakup perubahan, pemberitahuan, observasi, dan rollback sehingga klien yang tidak dikenal tidak terputus secara mendadak.
Kesalahan umum
- Memperdebatkan label URL, header, atau semantic versioning tanpa penemuan konsumen dan bukti penghentian.
- Hanya mengandalkan pencarian kode statis atau satu log akses sehingga melewatkan panggilan dinamis dan langka.
- Menganggap menghapus field opsional otomatis aman tanpa menguji parsing klien yang sebenarnya.
- Meluncurkan versi baru dan langsung menutup versi lama tanpa peluncuran bertahap atau rollback.
- Mendukung setiap versi selamanya tanpa memperhitungkan biaya pengujian, pemantauan, dan konversi.
- Mengirimkan satu email tanpa batas waktu, pemilik, jalur eskalasi, atau metrik yang tersegmentasi.
Pertanyaan lanjutan dan tanggapan
Bagaimana Anda memutuskan untuk mematikan layanan ketika klien eksternal tidak dapat ditemukan?
Perlakukan penggunaan yang tidak diketahui sebagai status risiko, perpanjang jendela observasi, tingkatkan telemetri, dan hubungi pemilik sesuai kontrak atau tawarkan diagnostik migrasi. Nol log tidak membuktikan nol penggunaan; gunakan kebijakan penolakan yang dapat dipulihkan dan fallback darurat sebelum penghentian.
Apakah menambahkan field respons selalu kompatibel?
Tidak. Aturan mungkin mengklasifikasikannya sebagai umumnya kompatibel, tetapi replay konsumen nyata, matriks SDK, dan sampel error tetap perlu memvalidasinya. Schema validator yang ketat mungkin memerlukan migrasi terpisah atau batasan versi baru.
Bagaimana cara memigrasikan data yang ditulis oleh klien lama secara aman?
Definisikan pemetaan semantik dan kondisi bebas kehilangan data terlebih dahulu, lalu gunakan dual read, dual write, atau konversi offline dengan catatan versi. Konversi harus dapat diverifikasi dan dapat dibatalkan; jangan mengubah arti bisnis secara diam-diam pada saat pembacaan data.
Bagaimana jika pelanggan tidak dapat meningkatkan versi sebelum batas waktu?
Tawarkan jendela kompatibilitas terbatas, adapter, atau bantuan migrasi sesuai kontrak dan risiko, dengan mencatat biaya, pemilik, dan tanggal akhir yang baru. Pengecualian harus bertujuan mengurangi traffic yang tidak dikenal, bukan menjadikan versi lama permanen.
Bagaimana Anda mencegah control plane menjadi single point of failure?
Perutean data-plane tidak boleh memerlukan penulisan langsung ke control plane secara real-time. Simpan kebijakan versi yang disetujui dalam cache dan pertahankan konfigurasi aman terakhir selama kegagalan control plane. Layanan registri, pemberitahuan, dan metrik dapat pulih secara asinkron, sementara penghentian memerlukan persetujuan ganda dan rollback eksplisit.