Konsep baru melekat kalau kita melihatnya bekerja pada masalah nyata. Sepanjang section ini kita sudah membahas definisi data engineering, peran-peran tetangganya, siklus hidup data, arsitektur sistem, gaya pemrosesan, hingga platform. Sekarang saatnya merangkai semuanya dalam dua studi kasus berkonteks Indonesia: pipeline analitik pesanan untuk e-commerce menengah, dan pemantauan transaksi berbasis streaming untuk aplikasi fintech. Keduanya sengaja dipilih karena mewakili dua kutub kebutuhan — analitik berkala yang mengutamakan kelengkapan, dan deteksi seketika yang mengutamakan latensi.

Studi Kasus 1: Pipeline Analitik Pesanan E-Commerce #

Bayangkan “TokoLoka”, toko daring dengan sekitar 50 ribu pesanan per bulan. Tim manajemen ingin dashboard penjualan harian yang bisa dipercaya: total pendapatan, produk terlaris, dan performa per kota. Sampai saat ini, laporan dirakit manual dari export spreadsheet setiap minggu — lambat, dan angkanya kerap berbeda antar tim.

Data mengalir melalui tahapan berikut:

Mari kita telusuri langkah demi langkah:

  1. Sumber data: Order Service mencatat pesanan di database PostgreSQL ; status pembayaran datang dari payment gateway melalui webhook.
  2. Ingestion: job terjadwal di Airflow menarik perubahan pesanan setiap 15 menit (pola CDC — change data capture), sementara event webhook ditampung dari sisi gateway.
  3. Raw layer: setiap hasil tarikan disimpan apa adanya di object storage, diberi partisi per jam, sehingga proses bisa diulang bila transformasi keliru.
  4. Transformasi: dbt membersihkan data mentah — menstandarkan status pesanan, menggabungkan data pembayaran, mendeduplikasi webhook yang terkirim dua kali — lalu menyusun tabel fact_orders beserta dimensi produk dan kota.
  5. Serving: dashboard membaca langsung dari fact_orders; laporan mingguan cukup query tabel yang sama. Satu definisi angka untuk semua tim.

Hasilnya: dashboard tersedia tiap pagi dengan data selang 15 menit terakhir, dan selisih angka antar tim berhenti karena semua pihak membaca sumber yang sama.

Studi Kasus 2: Pemantauan Transaksi Fintech #

Kasus kedua: “BayarCepat”, aplikasi pembayaran yang harus memeriksa setiap transaksi dalam hitungan detik. Tim risiko ingin menandai transaksi yang tidak wajar — misalnya satu akun mentransfer ke puluh akun baru berbeda dalam lima menit — sambil tetap menyimpan seluruh jejak untuk audit. Kebutuhan latensi rendah membuat pola batch tidak cocok; streaming dipilih sejak awal.

Alurnya berjalan sebagai berikut:

  1. Producer: aplikasi mobile mengirim event transaksi ke topic Kafka begitu pengguna menekan tombol bayar.
  2. Stream processor: pekerja stream memantau jendela lima menit — menghitung jumlah penerima unik, frekuensi transfer, dan simpangan nominal dari kebiasaan akun.
  3. Alert engine: event yang melampaui ambang batas langsung diteruskan ke antrean verifikasi; pengguna melihat permintaan konfirmasi tambahan, bukan penolakan langsung.
  4. Sink dan audit: seluruh event — termasuk yang lolos — ditulis ke object storage sebagai jejak lengkap; job batch Spark menyusun laporan kepatuhan harian dari jejak tersebut.

Perhatikan pembagian kerjanya: streaming menangani keputusan seketika, batch menangani kelengkapan untuk audit. Kombinasi keduanya, bukan salah satu saja, adalah jawaban atas kebutuhan tim risiko.

Pelajaran dari Kedua Studi Kasus #

Dua kasus tersebut berbeda gaya, tetapi pola pengambilan keputusannya sama. Pertama, kebutuhan menentukan arsitektur: TokoLoka cukup dengan batch 15 menit karena pengambil keputusan membaca dashboard pagi; BayarCepat wajib streaming karena keputusan harus mendahului selesainya transaksi. Kedua, tahapan siklus hidup data sama di keduanya — generation, ingestion, storage, transformation, serving — yang berbeda hanya alat dan waktu pemrosesan. Ketiga, layer mentah selalu disimpan: bila aturan deteksi berubah atau transformasi keliru, pengolahan diulang dari jejak yang sama tanpa kehilangan bukti.

Dengan selesainya studi kasus ini, kita telah menuntaskan bagian pengenalan. Sebelum melangkah ke materi teknis, ada baiknya kita memeriksa bekal yang dibutuhkan — section Prasyarat Data Engineering memetakan keterampilan dasar yang akan sering dipakai sepanjang Course ini.