Siklus hidup hasil
Model data untuk hasil registrasi Telegram dan upaya pembaruan
Simpan field respons registrasi Telegram, bedakan hasil yang selesai dari error API, dan pertahankan tanda waktu respons lokal.
Mengapa satu boolean tidak cukup
Hasil registrasi Telegram adalah observasi bertanda waktu yang dihasilkan oleh pemeriksaan yang selesai, bukan kebenaran permanen yang melekat pada sebuah nomor telepon.
Field seperti telegram_valid kehilangan konteks penting. Field tersebut tidak menyebutkan nomor ternormalisasi mana yang diperiksa, kapan pemeriksaan dijalankan, apakah false merupakan keputusan yang selesai, atau apakah permintaan sebenarnya gagal. Basis data sebaiknya mempertahankan perbedaan tersebut agar aplikasi dapat menampilkan dan memperbarui hasil secara jujur.
TG Validator mengembalikan keputusan yang selesai secara sinkron, artinya observasi dapat ditulis segera setelah respons HTTP diterima. Field yang dikembalikan sebaiknya disimpan apa adanya, tanpa mengarang kumpulan status produk lain.
Pisahkan subjek dari observasinya
Gunakan satu catatan telepon internal yang stabil dan lampirkan beberapa observasi pemeriksaan padanya. Cara ini menghindari penulisan ulang riwayat dan membuat pembaruan berikutnya mudah dipahami.
| Catatan | Field yang disarankan | Tujuan |
|---|---|---|
| Sumber telepon | phone_id, source_phone, source_system |
Mempertahankan catatan bisnis asli |
| Telepon ternormalisasi | phone_id, e164_phone, normalized_at |
Mencatat nilai kanonis yang digunakan untuk pemeriksaan |
| Observasi pemeriksaan | phone_id, service_type, registered, received_at |
Menyimpan satu hasil sinkron |
Jika normalisasi berubah karena konteks negara aslinya dikoreksi, buat catatan kanonis baru atau beri versi pada catatan tersebut. Jangan diam-diam melampirkan hasil Telegram lama ke nomor telepon yang baru ditafsirkan ulang.
Gunakan bentuk respons yang persis seperti dokumentasi
| Bentuk yang dikembalikan | Nilai registered |
Arti |
|---|---|---|
code=0, data.registered=true |
true | Pemeriksaan yang selesai melaporkan terdaftar |
code=0, data.registered=false |
false | Pemeriksaan yang selesai melaporkan tidak terdaftar |
code API bukan nol |
Tidak ada | Tidak ada keputusan registrasi; error API, bukan hasil registrasi |
Perbedaan ini disengaja. Kode API bukan nol berarti layanan tidak memiliki jawaban boolean untuk disimpan. Masukan tidak valid, penolakan konkurensi, saldo tidak mencukupi, pemeliharaan, dan kegagalan internal tidak menambahkan nilai lain ke data.registered.
Pertahankan status terkini dan upaya terakhir sebagai dua tampilan
Dua pertanyaan sering kali berguna:
- Apa observasi registrasi terbaru yang sudah selesai?
- Apa yang terjadi pada upaya permintaan terbaru?
Keduanya bisa mengarah ke baris yang berbeda. Jika hasil true yang selesai pada T1 diikuti oleh error API pada T2, observasi terbaru yang selesai tetaplah true pada T1, sementara log permintaan terpisah dapat mencatat status HTTP dan kode API dari T2. Ini mencegah operator mengira T1 sebagai hasil baru atau T2 sebagai false.
Ketika panggilan berikutnya selesai dengan false pada T3, tampilan terkini yang selesai bergeser ke T3. Catatan T1 dan T2 tetap tersedia untuk audit dan pemecahan masalah.
Tentukan kapan pembaruan diperlukan
TG Validator memberikan observasi sinkron terkini saat dipanggil, tetapi aplikasi yang mengintegrasikannya yang menentukan kebijakan kesegaran data. Pilih usia maksimum yang dapat diterima berdasarkan keputusan yang akan diambil, lalu tampilkan usia tersebut di antarmuka.
Kebijakan pembaruan sebaiknya menetapkan:
- usia maksimum yang diterima untuk setiap alur kerja;
- apakah operator boleh menggunakan hasil lama yang sudah selesai setelah terjadi error API berikutnya;
- respons API bukan nol mana yang sebaiknya dikirim ulang nanti;
- bagaimana batas konkurensi per pengguna memengaruhi penjadwalan;
- apakah setiap upaya atau hanya observasi yang selesai yang disimpan dalam jangka panjang.
Jangan mencoba ulang registered=false yang sudah selesai hanya karena nilainya false. Coba ulang ketika observasi terbaru pada titik waktu tertentu diperlukan atau ketika upaya sebelumnya tidak menghasilkan keputusan.
Kueri status terkini yang tepat
Status registrasi terkini sebaiknya memilih observasi terbaru dengan respons luar code=0, lalu mengembalikan nilai registered bersama received_at lokalnya. Jangan pernah mengembalikan boolean tanpa tanda waktunya.
Status upaya terakhir sebaiknya memilih observasi terbaru dengan status apa pun. Jika belum selesai, antarmuka dapat menjelaskan bahwa pemeriksaan yang lebih baru telah dicoba tanpa menggantikan hasil registrasi terakhir yang diketahui.
Prinsip desain yang tahan lama
Tambahkan observasi, pertahankan tanda waktunya, dan jangan pernah memaksakan ketidakpastian operasional menjadi nilai registrasi Telegram.
Model ini sesuai persis dengan produknya. TG Validator menjawab satu pertanyaan registrasi secara sinkron; produk ini tidak menyediakan data identitas atau profil akun. Aplikasi pelanggan menyediakan catatan yang stabil, kebijakan retensi, jadwal pembaruan, dan keputusan bisnis di seputar setiap observasi.