Merancang integrasi data antar sistem: perbedaan ETL dan ELT, peran API dalam integrasi data, pola integrasi yang terbukti, dan praktik menyusun strategi integrasi

Setelah di episode 15 kita merancang migrasi, sekarang kita membahas aktivitas yang mengisi hari-hari data platform: integrasi data. Setiap sistem — ERP, CRM, aplikasi mobile, platform iklan, file dari vendor — menghasilkan data dengan format dan keteraturannya sendiri, dan semuanya harus mengalir masuk ke satu arsitektur yang konsisten.
Mengapa episode ini penting? Karena jumlah sumber data terus bertambah, dan setiap sumber baru bisa menjadi sumber inkonsistensi jika integrasinya tidak dirancang. Arsitek yang memahami pola integrasi bisa menilai: sumber ini cukup di-pull berkala, atau perlu streaming; pakai tool atau bangun sendiri; dan bagaimana menjaga kualitas di sepanjang jalan.
| Aspek | ETL | ELT |
|---|---|---|
| Urutan | Transform sebelum load | Load dulu, transform di warehouse |
| Lokasi transform | Staging server / middleware | Warehouse/lakehouse (komputasi di sana) |
| Kapan skema dipahami | Sebelum masuk | Belakangan (schema-on-read) |
| Alat | Informatica, SSIS, Talend | dbt, SQL, Spark |
| Cocok untuk | Warehouse kecil, data terstruktur | Cloud warehouse/lakehouse, volume besar |
Di 2026, ELT adalah default untuk arsitektur modern: data mentah masuk dulu (bronze), transformasi dilakukan di platform (silver/gold) dengan SQL/dbt. Alasannya: cloud compute murah dan bisa di-scale, sementara pembersihan di middleware menjadi bottleneck yang sulit di-debug.
ETL: source → [transform di staging] → warehouse → BI
ELT: source → warehouse (raw) → [transform via dbt] → gold → BINote
Ada kalanya transformasi ringan tetap layak dilakukan sebelum load — misal normalisasi timestamp atau dedup sederhana saat ingestion. Prinsipnya: simpan data mentah seautentik mungkin; transformasi yang butuh konteks bisnis dilakukan di platform, bukan di middleware.
Pola paling dasar: tarik data dari sumber secara berkala.
setiap 60 menit: read API/tabel sumber → tulis bronze → transformasi
cocok untuk: sumber tanpa kebutuhan real-time, file export, API rate-limitedSudah dibahas di episode 7: alirkan perubahan DB via log. Ini pola terbaik untuk sinkronisasi antar database dan aplikasi.
Untuk sistem SaaS (CRM, billing, marketing), integrasi lewat API adalah standar. Poin arsitektural yang sering salah: menarik seluruh dataset setiap kali alih-alih memakai incremental endpoint.
- endpoint incremental (updated_since) → hanya ambil perubahan
- retry + backoff eksponensial → API rate limit
- idempotent upsert di sisi tujuan → aman di-run ulang
- simpan raw response di bronze → bisa di-reprosesUntuk decoupling antar sistem: produsen menerbitkan event (Kafka/Pub-Sub), konsumen memproses. Ini pola interop yang paling fleksibel — kita bahas lebih dalam sebagai arsitektur event-driven di episode 7.
Interoperability adalah kemampuan sistem berbeda untuk saling memahami data. Tanpa itu, setiap integrasi jadi proyek custom. Fondasinya:
customer_id global).Pola anti yang harus dihindari: file dump yang formatnya berubah-ubah, atau spreadsheet yang di-upload manual sebagai "integrasi".
| Kategori | Contoh | Kapan Dipakai |
|---|---|---|
| Managed connectors | Fivetran, Airbyte, Stitch | Banyak SaaS connectors, tim kecil |
| Framework open source | Airbyte self-host, Singer, Meltano | Butuh kontrol penuh |
| Custom ingestion | Python + API client | Sumber internal/non-standar |
| CDC | Debezium, Fivetran DB, DMS | Sinkronisasi database |
Aturan praktis untuk arsitek: pakai managed connector untuk sumber standar (SaaS populer), dan custom ingestion untuk sumber internal yang tidak didukung vendor. Membangun sendiri connector SaaS yang sudah didukung adalah pemborosan.
Tip
Prinsip integrasi yang sering diabaikan: simpan respons mentah apa adanya di bronze sebelum transformasi apa pun. Vendor API mengubah format, kolom, atau makna — jika kalian hanya menyimpan hasil transformasi, kalian kehilangan kemampuan re-proses dan audit saat vendor mengubah formatnya.
sumber tipe pola frekuensi tool kualitas
ERP on-prem database CDC/ETL batch tiap 30 menit Debezium unique check
Salesforce SaaS API tiap jam Fivetran row count
Aplikasi kita database CDC near real-time Debezium fresh SLO
Vendor file file CSV batch pull harian custom schema checkSemua sumber masuk ke bronze layer dengan format dan metadata yang konsisten (source, load_dt, record_source) — siap diproses pipeline yang sama.
Terapkan checks (episode 9) di tiap integrasi: schema drift terdeteksi dini, row count anomali ber-alert, dan format tak terduga masuk DLQ — bukan merusak downstream.
Inti yang harus dibawa pulang:
Di episode 17 selanjutnya kita akan membahas Reference & Enterprise Architecture — cara menetapkan standar dan blueprint arsitektur data yang konsisten lintas seluruh domain. Sampai jumpa di episode 17!