Daftar isi
Masalah dan batasan
Ini studi kasus pembelajaran ilustratif, bukan sistem yang telah diterapkan atau pekerjaan klien. Masukannya adalah transaksi sintetis. Tidak ada pelanggan, kredensial, repositori produksi, hasil pengukuran kinerja, atau klaim dampak bisnis.
Pertanyaan rancangannya konkret: bagaimana batch harian menerima transaksi terlambat, menolak baris salah format, dan menghasilkan model yang sama setelah pengulangan? Anggap setiap baris memiliki ID transaksi, waktu kejadian, jumlah, mata uang, dan ID batch sumber. Jumlah uang memakai representasi desimal eksak. Kontrak batch mewajibkan mata uang; jumlah dengan mata uang berbeda tidak boleh dijumlahkan tanpa kebijakan konversi yang jelas.
Arsitektur
Simpan masukan asli tanpa perubahan, disertai manifes batch dan checksum. Gerbang kualitas memeriksa ID wajib, pembacaan waktu, mata uang, presisi jumlah, dan ID transaksi yang berkonflik. Baris valid masuk tabel staging. Baris tidak valid mempertahankan referensi sumber dan kode alasan di karantina; tidak ada penghapusan diam-diam. Perubahan skema menggagalkan batch untuk ditinjau, bukan menebak arti kolom baru.
Keluaran analitik memiliki satu baris per hari kejadian dan mata uang. Keunikan staging menggunakan ID transaksi beserta kebijakan versi dari kontrak sumber. Pengulangan mengganti keluaran hari terdampak secara atomik dari staging yang tervalidasi. Buku catatan batch merekam checksum masukan, versi aturan, dan status selesai agar pengulangan dapat membedakan masukan yang sama dari masukan yang telah diperbaiki.
Peran, alat, dan pendekatan
Perannya adalah menyusun latihan rancangan untuk pembelajaran. Python diusulkan untuk pemasukan dan validasi; SQL menjelaskan batasan staging dan agregasi harian. Penyimpanan objek dan gudang data relasional adalah peran arsitektur, tanpa memilih vendor atau layanan berbayar. Alat ini komponen usulan, bukan klaim adanya repositori yang dapat dijalankan.
Mulai dengan fixture deterministik: batch bersih, ID duplikat, waktu hilang, desimal tidak valid, baris terlambat, dan batch yang diperbaiki. Tentukan alasan karantina dan keluaran yang diharapkan untuk tiap kasus. Pemeriksaan utamanya adalah kesamaan keluaran setelah menjalankan batch identik dua kali. Kegagalan antara staging dan publikasi harus mempertahankan model harian lengkap terakhir.
Hasil dan keterbatasan
Hasilnya adalah dokumentasi rancangan dan invariannya; tidak ada klaim benchmark implementasi atau pengujian yang telah dijalankan. Usulan evaluasi mencakup rekonsiliasi jumlah baris diterima dan dikarantina, keunikan staging, serta total harian terpisah per mata uang. Semuanya tetap usulan pemeriksaan untuk implementasi berikutnya.
Kejadian terlambat memerlukan pembangunan ulang partisi hari kejadian, bukan hanya memproses tanggal pemasukan hari ini. Penanganan pengembalian dana dan perubahan data sumber memerlukan kebijakan versi yang disepakati sebelum implementasi. Penulis bersamaan juga memerlukan penguncian atau kebijakan isolasi transaksi; buku catatan saja tidak mencegah publikasi yang tumpang tindih.
Pelajaran dan eksperimen berikutnya
Idempotensi bergantung pada kontrak masukan, kunci, dan batas publikasi bersama-sama. Menyimpan baris ditolak membuat pemulihan dapat diperiksa. Berikutnya, buat fixture lokal kecil dan simulasikan kegagalan sebelum publikasi, lalu bandingkan hasilnya dengan pengulangan bersih. Contoh ini tidak membuktikan kesiapan produksi.