Sistem Upload dengan Proses Berat dan Lama di Backend (Asynchronous)
3 min read Software Engineering

Sistem Upload dengan Proses Berat dan Lama di Backend (Asynchronous)

Dalam banyak sistem enterprise, user sering kali perlu meng-upload file besar (misalnya Excel, CSV, atau ZIP) yang kemudian diproses dengan logic kompleks: validasi data, transformasi, enrichment, hingga penyimpanan ke database. Proses ini bisa memakan waktu beberapa menit (misalnya ±5 menit).

Pendekatan synchronous jelas bukan pilihan karena:

  • Request HTTP akan timeout
  • User experience sangat buruk
  • Resource backend akan terkunci lama

Solusi yang tepat adalah arsitektur asynchronous processing dengan mekanisme monitoring status oleh user.

Gambaran Besar Solusi

Ide dasarnya adalah memisahkan:

  1. Upload & acceptance (cepat)
  2. Heavy processing (lama, asynchronous)
  3. Monitoring & observability (status ke user)

User tidak perlu menunggu proses selesai, cukup tahu bahwa:

  • File sudah diterima
  • Proses sedang berjalan / selesai / gagal

Flow Tingkat Tinggi

  1. User upload file
  2. Backend menyimpan file (object storage)
  3. Backend mencatat task ke database (queue-like table)
  4. Backend langsung response ke user
  5. Worker / processor memproses task secara asynchronous
  6. Status proses di-update dan dapat dimonitor oleh user

Diagram Arsitektur

Sistem Upload dengan Proses Berat dan Lama di Backend (Asynchronous)

Data Model (Contoh)

Tabel upload_tasks:

  • id
  • user_id
  • file_path
  • status (PENDING | PROCESSING | DONE | FAILED)
  • progress (0–100, optional)
  • error_message
  • created_at
  • updated_at

Tabel ini berfungsi sebagai:

  • Antrian proses
  • Sumber data monitoring
  • Audit & history

UX & User Flow

Saat Upload

  • User upload file

  • Sistem langsung menampilkan pesan:

    “File berhasil di-upload dan sedang diproses”

Halaman Status

  • List history upload
  • Status per file
  • Waktu upload & update terakhir

Halaman Detail

  • Status detail
  • Progress (jika ada)
  • Error message jika gagal

Backend Processing – Dua Pendekatan

Opsi 1: CLI Worker (Running Forever)

Karakteristik:

  • Program (Golang, dll) berjalan terus
  • Setiap X detik (misalnya 5 detik) query DB
  • Ambil task berstatus PENDING
  • Lock task → PROCESSING
  • Proses → DONE / FAILED

Kelebihan:

  • Sederhana
  • Bisa di-deploy sebagai container (EC2 / VM / Cloud Run)
  • Cocok untuk on-prem atau non-cloud-native

Kekurangan:

  • Polling tidak efisien
  • Scaling manual
  • Idle resource ketika tidak ada task

Opsi 2: AWS SQS + Lambda (Event-Driven)

Karakteristik:

  • Saat upload, backend push message ke SQS
  • Setiap task = 1 message
  • Lambda / worker otomatis dipanggil
  • Auto-scaling

Kelebihan:

  • Benar-benar event-driven
  • Tidak ada polling
  • Scaling otomatis
  • Cost efektif untuk workload tidak konstan

Kekurangan:

  • Lebih banyak komponen
  • Perlu memahami retry, DLQ, visibility timeout

EventBridge + Lambda (Alternatif Hybrid)

Pendekatan lain adalah:

  • EventBridge cron (misalnya tiap 1 menit)
  • Lambda scan DB untuk task PENDING

Ini cocok jika:

  • Tidak ingin SQS
  • Task rate rendah
  • Arsitektur tetap serverless

Namun secara prinsip, SQS lebih tepat untuk use case queue.

Error Handling & Reliability

Best practice:

  • Status PROCESSING harus atomic (SELECT FOR UPDATE)
  • Retry terbatas
  • Dead-letter (FAILED setelah N kali retry)
  • Simpan error message untuk debugging

Kesimpulan

Arsitektur asynchronous upload + heavy processing adalah mandatory untuk sistem modern dengan workload berat.

  • Pisahkan upload dan processing
  • Gunakan status tracking
  • Pilih worker model sesuai skala

Untuk skala kecil → CLI worker cukup Untuk skala production → SQS + Lambda adalah pilihan ideal

Artikel selanjutnya akan membahas contoh implementasi menggunakan Golang, lengkap dengan struktur kode dan flow processing.