Petunjuk dan ruang lingkup
Sistem pemesanan menghasilkan 200 juta transaksi per hari. Buku besar internal mencatat pesanan, pembayaran, pengembalian dana, dan biaya; penyedia pembayaran memasok laporan batch penyelesaian; bank memasok setoran aktual. Rancang pipeline T+1 yang selesai sebelum pukul 06:00 untuk hari sebelumnya, mengidentifikasi perbedaan data yang hilang, duplikat, jumlah, biaya, dan mata uang, serta mendukung eksekusi ulang, peninjauan manual, pengembalian dana, multi-mata uang, dan jejak audit.
Asumsikan buku besar internal adalah sumber kebenaran (source of truth) bisnis, sedangkan penyedia dan bank adalah sumber kebenaran eksternal. Rekonsiliasi tidak boleh menimpa buku besar atau menyembunyikan perbedaan tingkat baris hanya karena jumlah totalnya kebetulan sama. Jumlah, mata uang, tanggal penyelesaian, batch, dan bukti harus tetap dapat dilacak.
Apa yang sedang diuji oleh pewawancara
Pertama, dapatkah Anda menentukan fakta, waktu, dan invarian sebelum memilih alat? Bedakan tanggal transaksi, tanggal pembukuan (posting date), tanggal penyelesaian (settlement date), dan tanggal nilai bank (value date). Simpan uang dalam unit minor (minor units), wajibkan mata uang, dan pastikan proses impor berulang berjalan aman.
Kedua, dapatkah Anda menjadikan pencocokan sebagai strategi berlapis daripada sekadar full-table join? Mulailah dengan ID transaksi penyedia dan ID batch, lalu gunakan kombinasi terbatas dari ID pesanan, jumlah, mata uang, dan rentang waktu. Pencocokan fuzzy harus masuk ke peninjauan daripada dikonfirmasi secara diam-diam.
Ketiga, dapatkah Anda menutup siklus diskrepansi? Setiap diskrepansi memerlukan tipe, tingkat keparahan, bukti, pemilik, status, batas waktu, dan tindakan perbaikan. Sebuah perbaikan membuat versi rekonsiliasi baru sambil tetap mempertahankan diskrepansi aslinya.
Pertanyaan untuk diklarifikasi sebelum menjawab
- Apa saja yang masuk dalam ruang lingkup? Otorisasi, capture, refund, biaya, pencairan dana (payout), setoran bank, atau semuanya?
- Zona waktu mana yang menentukan pukul 06:00? Bisakah penyelesaian dan pembuatan laporan melintasi perubahan daylight-saving atau hari libur?
- Bisakah laporan eksternal diambil secara inkremental? Apakah nama file, kursor, versi, dan unduhan yang dapat diulang bersifat stabil?
- Bolehkah pipeline menyesuaikan buku besar secara otomatis? Asumsikan pipeline membuat usulan penyesuaian yang disetujui oleh alur kerja berwenang.
- Kebijakan FX mana yang berlaku? Pertahankan mata uang transaksi, penyelesaian, dan bank, serta tentukan sumber kurs dan presisinya.
- Berapa SLA penyelesaiannya? Tentukan eskalasi untuk diskrepansi bernilai tinggi, terkait kepatuhan, dan yang berdampak pada pelanggan.
Kerangka jawaban 30 detik
"Pertama, saya akan mempertahankan ketiga sumber dalam lapisan mentah (raw) yang tidak dapat diubah (immutable), lalu menormalisasi jumlah, mata uang, waktu, dan ID eksternal. Impor bersifat idempoten berdasarkan versi laporan; kunci kuat dicocokkan terlebih dahulu, kunci komposit terbatas kedua, dan hasil yang tidak pasti masuk ke antrean peninjauan. Setiap batch mendapatkan kontrol tingkat baris, grup, dan total. Diskrepansi menggunakan state machine yang dapat diaudit dan diperbaiki melalui entri penyesuaian yang disetujui. Saya menjadwalkan mundur dari batas waktu, memantau kelengkapan file, latensi, tingkat kecocokan, jumlah terbuka, dan eksekusi ulang, serta menguji file duplikat, refund yang terlambat, penyelesaian parsial, dan perubahan FX."
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan model fakta dan jendela akuntansi
Buat fakta internal_entry, provider_entry, dan bank_entry yang tidak dapat diubah. Simpan hash file sumber, nomor baris, sumber, waktu penyerapan (ingest), versi laporan, tanggal bisnis, dan tanggal penyelesaian. Simpan uang sebagai unit minor bilangan bulat, jangan pernah menggunakan floating point, dan wajibkan mata uang. Pisahkan status pesanan dari status dana sehingga "pembayaran berhasil" tidak dianggap sebagai "kas telah diterima."
Langkah 2: Serap data secara idempoten berdasarkan versi sumber
Tulis unduhan ke penyimpanan objek terlebih dahulu, lalu validasi ukuran, hash, tanda tangan, dan jumlah baris yang diharapkan. Gunakan source + report_id + version + row_number sebagai kunci unik. Unduhan duplikat menambahkan catatan penyerapan tetapi tidak dapat membukukan uang dua kali. Pertahankan versi lama dari penyedia dan catat hubungan penggantian alih-alih menimpa file.
unique_key = source + report_id + version + row_number
if unique_key already exists: record_duplicate_download()
else: persist_raw_row()Langkah 3: Bangun lapisan normalisasi yang dapat dijalankan ulang
Petakan status, tanda jumlah, zona waktu, jenis biaya, dan ID eksternal melalui kamus berversi. Setiap transformasi menulis normalization_run_id; snapshot input yang tetap dan versi aturan membuat eksekusi ulang bersifat deterministik. Status yang tidak diketahui, semantik jumlah negatif, dan mata uang masuk ke karantina alih-alih menjadi nol secara default.
Langkah 4: Gunakan pencocokan berlapis
Lapisan satu menggunakan ID transaksi penyedia, refund, dan payout yang stabil. Lapisan dua menggunakan ID pesanan, jumlah, dan rentang waktu yang diizinkan dalam merchant, mata uang, dan tanggal penyelesaian yang sama. Lapisan tiga hanya menghasilkan kandidat; jumlah yang sama dalam mata uang berbeda, satu item internal yang terbagi di beberapa baris eksternal, dan satu baris eksternal yang terbagi di beberapa penyelesaian, semuanya memerlukan peninjauan.
Langkah 5: Buktikan hasil dengan tiga kontrol
Kontrol baris memverifikasi bahwa setiap fakta dicocokkan paling banyak satu kali. Kontrol grup membandingkan jumlah hitungan dan nominal berdasarkan batch, mata uang, tanggal penyelesaian, dan jenis biaya. Kontrol total membandingkan saldo awal, arus masuk, arus keluar, biaya, refund, dan saldo akhir di seluruh buku besar, laporan penyedia, dan setoran bank. Pertahankan bukti untuk setiap lapisan ketika terjadi ketidaksesuaian; jangan hanya menampilkan satu tanda "lulus".
Langkah 6: Jadikan diskrepansi sebagai state machine
Minimal klasifikasikan data yang hilang, duplikat, ketidakcocokan jumlah, ketidakcocokan biaya, ketidakcocokan mata uang atau FX, pergeseran tanggal, dan status eksternal yang tidak diketahui. Status dapat berupa open, investigating, adjustment_pending, resolved, dan accepted, dengan pelaku, alasan, bukti, dan stempel waktu pada setiap transisi. Diskrepansi bernilai tinggi atau terkait kepatuhan memerlukan persetujuan dua orang; otomatisasi hanya boleh membuat usulan.
Langkah 7: Tangani data terlambat, refund, dan penyelesaian parsial
Ketika sebuah laporan terlambat, tutup hanya ruang lingkup yang telah diterima dan biarkan batch tersebut belum lengkap. Jangan mengubah ketiadaan sementara menjadi catatan hilang yang permanen. Refund dan sengketa dapat tiba setelah tanggal transaksi, jadi catat tanggal peristiwa dan tanggal penyelesaian secara terpisah. Pertahankan hubungan one-to-many ketika sebuah transaksi dibagi ke beberapa payout; saldo yang sama tidak menghapus baris yang belum cocok.
Langkah 8: Rencanakan pemulihan, eksekusi ulang, dan audit
Simpan manifes file input, waktu snapshot, versi aturan, hasil pencocokan, dan diskrepansi keluaran untuk setiap eksekusi. Mulai ulang dari tahap sukses terakhir, isolasi keluaran eksekusi ulang berdasarkan ID eksekusi, dan gabungkan berdasarkan kunci unik. Simpan file mentah, hash, versi laporan, keputusan manusia, dan voucher penyesuaian untuk ketertelusuran berdasarkan batch, transaksi, atau diskrepansi. Stripe juga memisahkan saldo, transaksi, dan payout serta merekomendasikan penggunaan payout ID untuk mengambil transaksi saldonya, menunjukkan mengapa batch penyelesaian eksternal tidak dapat direduksi menjadi satu total saja.
Trade-off dan batasan
Trade-off 1: Kunci kuat atau tingkat pencocokan yang lebih tinggi
Otomatisasi kunci kuat mungkin mencocokkan lebih sedikit baris, tetapi biaya false-positive terkendali. Rentang jumlah dan waktu yang lebih luas meningkatkan cakupan sekaligus meningkatkan kemungkinan penggabungan transaksi serupa. Buat versi untuk ambang batas, rentang waktu, dan fallback; kirim setiap hasil non-deterministik ke peninjauan.
Trade-off 2: Batch harian atau mendekati real-time
Batch T+1 lebih mudah direproduksi dan diaudit. Aliran mendekati real-time memunculkan masalah bernilai tinggi lebih awal tetapi harus menangani versi laporan, data terlambat, dan peristiwa duplikat. Gunakan batch sebagai kesimpulan akuntansi dan aliran data sebagai lapisan peringatan.
Trade-off 3: Penyesuaian otomatis atau persetujuan manusia
Perbedaan kecil, eksplisit, dan dapat dibalikkan dapat menggunakan otomatisasi terbatas. Perbedaan bernilai tinggi, mata uang, tagihan ganda, dan kepatuhan memerlukan persetujuan manusia. Kedua jalur mempertahankan fakta asli dan voucher penyesuaian daripada mengedit riwayat.
Latihan kegagalan dan rencana evolusi
Latihan 1: File dan baris duplikat
Kirim laporan yang sama tiga kali dan verifikasi bahwa hash file, versi laporan, dan kunci baris mencegah pembukuan ganda. Masukkan satu transaksi ke dalam dua versi dan verifikasi bahwa hubungan versi dan aturan pemilihan dapat dijelaskan.
Latihan 2: Refund terlambat dan penyelesaian parsial
Kirimkan refund dua hari setelah penyelesaian dan bagi satu pesanan ke dalam dua payout. Verifikasi bahwa tanggal transaksi, penyelesaian, dan setoran tetap terpisah, dan bahwa eksekusi baru menyelesaikan diskrepansi tanpa mengubah eksekusi historis.
Latihan 3: Halaman hilang dan kurs FX salah
Hapus satu halaman laporan atau ganti tabel kurs. Kontrol jumlah baris, hash, total, dan mata uang harus memblokir publikasi dan menandai batch menunggu penyelesaian alih-alih menyatakannya telah terekonsiliasi.
Kesalahan umum dan tindak lanjut
Kesalahan 1: Hanya membandingkan tiga total
Total yang sama dapat menyembunyikan satu baris hilang dan satu baris duplikat. Pertahankan pencocokan baris, kontrol grup, dan kontrol total.
Kesalahan 2: Menyimpan uang sebagai floating point
Kesalahan floating point menciptakan perbedaan palsu. Gunakan unit minor bilangan bulat atau desimal tetap dan selalu simpan mata uang.
Kesalahan 3: Menimpa laporan lama
Menimpa data menghancurkan bukti audit dan eksekusi ulang. Simpan laporan secara tidak dapat diubah dan nyatakan koreksi sebagai versi baru.
Kesalahan 4: Membukukan pencocokan fuzzy secara otomatis
Jumlah yang sama dan waktu yang berdekatan tidak membuktikan identitas transaksi. Masukkan hasil fuzzy ke dalam peninjauan bersama bukti kandidat.
Kesalahan 5: Menganggap pembayaran sukses sebagai setoran bank
Status pembayaran, penyelesaian penyedia, dan setoran bank adalah fakta yang berbeda. Modelkan secara terpisah dan hubungkan melalui relasi batch.
Kesalahan 6: Mengabaikan pembuatan laporan dan zona waktu
Laporan mungkin baru tersedia setelah penyelesaian; zona waktu dan hari libur menciptakan data hilang yang palsu. Jadwalkan berdasarkan komitmen ketersediaan sumber dan simpan zona waktu secara eksplisit.
Kesalahan 7: Mengedit baris buku besar historis untuk memperbaiki masalah
Pengeditan langsung menghapus bukti asli. Gunakan entri penyesuaian yang disetujui yang ditautkan ke diskrepansi dan eksekusi baru.