Django dan Celery: Pemrosesan Tugas Asinkron dan Pertanyaan Wawancara 2026

Django dan Celery membentuk fondasi pemrosesan tugas asinkron dalam aplikasi web Python. Dengan Celery 5.6 dan Django 6.0 yang keduanya merilis pembaruan besar pada tahun 2026, pemahaman tentang antrian tugas terdistribusi tetap menjadi keterampilan kritis untuk wawancara backend dan sistem produksi.

Cara Celery Terintegrasi dengan Django

Celery beroperasi sebagai proses independen yang berbagi codebase proyek Django. Integrasi ini bergantung pada tiga komponen: aplikasi Django (producer), message broker (Redis atau RabbitMQ), dan satu atau lebih Celery worker (consumer). Ketika sebuah view Django memanggil .delay() atau .apply_async(), tugas diserialisasi dan didorong ke antrian broker. Worker mengambilnya dan mengeksekusi fungsi tersebut di prosesnya sendiri.

Pengaturan dimulai dengan modul celery.py di root proyek Django:

# myproject/celery.py
import os
from celery import Celery

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')

app = Celery('myproject')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.autodiscover_tasks()

Pemanggilan autodiscover_tasks() memindai setiap aplikasi Django yang terinstal untuk modul tasks.py, mendaftarkan semua fungsi yang didekorasi sebagai tugas Celery secara otomatis.

Di settings.py, broker dan result backend dikonfigurasi:

# myproject/settings.py
CELERY_BROKER_URL = 'redis://localhost:6379/0'
CELERY_RESULT_BACKEND = 'redis://localhost:6379/1'
CELERY_ACCEPT_CONTENT = ['json']
CELERY_TASK_SERIALIZER = 'json'
CELERY_RESULT_SERIALIZER = 'json'
CELERY_TIMEZONE = 'UTC'

Redis berfungsi ganda sebagai broker dan result backend di sebagian besar deployment Django. RabbitMQ tetap menjadi pilihan yang lebih baik untuk aplikasi yang memerlukan quorum queues atau routing tingkat lanjut, fitur yang sepenuhnya didukung sejak Celery 5.5.

Menulis dan Mengirim Tugas Celery

Tugas Celery adalah fungsi Python biasa yang didekorasi dengan @shared_task. Dekorator shared_task menghindari hardcoding instance aplikasi Celery, membuat tugas dapat digunakan kembali di seluruh aplikasi Django.

# orders/tasks.py
from celery import shared_task
from django.core.mail import send_mail
from orders.models import Order

@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def send_order_confirmation(self, order_id: int) -> str:
    """Send confirmation email for a completed order."""
    try:
        order = Order.objects.select_related('user').get(id=order_id)
        send_mail(
            subject=f'Order #{order.id} Confirmed',
            message=f'Your order totaling {order.total} has been confirmed.',
            from_email='noreply@example.com',
            recipient_list=[order.user.email],
        )
        return f'Email sent for order {order_id}'
    except Order.DoesNotExist:
        return f'Order {order_id} not found'
    except Exception as exc:
        # Retry on transient failures (SMTP timeout, etc.)
        raise self.retry(exc=exc)

Tiga pola kritis muncul di sini. Pertama, bind=True memberikan tugas akses ke self, memungkinkan retry. Kedua, fungsi menerima integer order_id alih-alih objek ORM — instance model tidak dapat diserialisasi secara andal melintasi batas proses. Ketiga, self.retry(exc=exc) memasukkan kembali tugas ke antrian dengan backoff eksponensial pada kegagalan sementara.

Mengirim dari view Django:

# orders/views.py
from orders.tasks import send_order_confirmation

def complete_order(request, order_id):
    # ... process payment, update order status ...
    send_order_confirmation.delay(order_id)
    return redirect('order_success', order_id=order_id)

Pemanggilan .delay() kembali segera. Pengguna melihat halaman sukses sementara tugas email berjalan di latar belakang.

Task Routing dan Manajemen Antrian

Sistem produksi tidak boleh mendorong semua tugas ke satu antrian default. Tugas pembuatan laporan yang lambat dapat membuat tugas notifikasi cepat kelaparan jika berbagi pool worker yang sama. Celery menyelesaikan ini dengan task routing.

# myproject/settings.py
CELERY_TASK_ROUTES = {
    'orders.tasks.send_order_confirmation': {'queue': 'notifications'},
    'reports.tasks.generate_monthly_report': {'queue': 'reports'},
    'images.tasks.resize_upload': {'queue': 'media'},
}

Worker kemudian dijalankan per antrian:

# Start notification worker (fast tasks, high concurrency)
celery -A myproject worker -Q notifications -c 8 --loglevel=info

# Start report worker (slow tasks, limited concurrency)
celery -A myproject worker -Q reports -c 2 --loglevel=info

# Start media worker (CPU-bound, prefork pool)
celery -A myproject worker -Q media -c 4 -P prefork --loglevel=info

Pemisahan ini mencegah kontesi sumber daya. Worker notifikasi menangani throughput tinggi dengan 8 thread konkuren, sementara worker laporan hanya menjalankan 2 tugas konkuren untuk menghindari kehabisan memori dari query dataset besar.

Tugas Berkala dengan Celery Beat

Celery Beat adalah scheduler bawaan untuk tugas berulang. Celery Beat berjalan sebagai proses terpisah yang mendorong tugas ke broker pada interval yang dikonfigurasi.

# myproject/settings.py
from celery.schedules import crontab

CELERY_BEAT_SCHEDULE = {
    'cleanup-expired-sessions': {
        'task': 'accounts.tasks.cleanup_expired_sessions',
        'schedule': crontab(hour=3, minute=0),  # Daily at 3 AM UTC
    },
    'sync-inventory': {
        'task': 'inventory.tasks.sync_external_inventory',
        'schedule': 300.0,  # Every 5 minutes
    },
    'generate-weekly-digest': {
        'task': 'notifications.tasks.send_weekly_digest',
        'schedule': crontab(hour=9, minute=0, day_of_week='monday'),
    },
}

Beat dijalankan bersamaan dengan worker:

celery -A myproject beat --loglevel=info

Kesalahan umum produksi: menjalankan beberapa instance Beat menyebabkan eksekusi tugas duplikat. Hanya satu proses Beat yang boleh berjalan per deployment. Alat seperti django-celery-beat menyimpan jadwal di database, memungkinkan modifikasi runtime melalui Django admin.

Monitoring dan Observabilitas dengan Flower

Flower menyediakan dashboard web real-time untuk memantau worker, tugas, dan antrian Celery. Flower mengekspos tingkat keberhasilan tugas, waktu eksekusi, kedalaman antrian, dan status worker.

# Install and run Flower
pip install flower
celery -A myproject flower --port=5555

Di produksi, metrik Flower harus dimasukkan ke sistem alerting. Kedalaman antrian yang bertumbuh dengan tugas stale mengindikasikan masalah kapasitas worker. Tingkat retry yang tinggi pada tugas tertentu menunjukkan ketidakstabilan layanan eksternal.

Celery 5.6 juga memperkenalkan peningkatan structured logging yang terintegrasi dengan agregator log JSON seperti Datadog atau ELK stack, memberikan efisiensi debugging 30% lebih baik menurut catatan rilis.

Framework Tugas Bawaan Django 6.0 vs. Celery

Django 6.0 mengirimkan framework tugas latar belakang native, memunculkan pertanyaan apakah Celery masih diperlukan. Jawabannya tergantung pada kasus penggunaan.

Framework tugas bawaan Django menangani operasi latar belakang sederhana — mengirim email, membersihkan cache, pemrosesan data ringan — tanpa memerlukan infrastruktur broker terpisah. Task runner dibangun di dalam Django itu sendiri.

Celery tetap esensial untuk:

• Pemrosesan terdistribusi di beberapa mesin
• Antrian prioritas dan task routing
• Rate limiting dan kebijakan retry tingkat lanjut
• Penjadwalan berkala (Celery Beat)
• Pelacakan hasil dengan backend yang dapat dikonfigurasi
• Canvas workflows (chains, groups, chords) untuk orkestrasi tugas kompleks

Untuk aplikasi yang hanya membutuhkan pekerjaan latar belakang fire-and-forget, solusi bawaan Django 6.0 mengurangi kompleksitas operasional. Untuk apa pun yang melibatkan worker terdistribusi, penjadwalan, atau komposisi tugas, Celery 5.6 adalah pilihan yang terbukti.

Pertanyaan Wawancara: Django dan Celery

Wawancara teknis untuk peran backend sering menguji pengetahuan Celery. Berikut adalah pertanyaan yang diambil dari skenario wawancara Django nyata di perusahaan mulai dari startup hingga FAANG.

T: Mengapa tugas harus menerima primary key alih-alih instance model?

Instance model Django membawa koneksi database, queryset, dan relasi lazy-loaded yang tidak dapat bertahan dari serialisasi. Mengoper order_id alih-alih objek Order memastikan tugas mengambil data segar dari database, menghindari state basi dan kesalahan serialisasi.

T: Bagaimana self.retry() berbeda dari mengirim ulang tugas secara manual?

self.retry() mempertahankan hitungan retry, menerapkan batas max_retries yang dikonfigurasi, dan menggunakan backoff eksponensial secara default. Memanggil .delay() secara manual lagi membuat tugas baru dengan counter retry yang direset, yang dapat menyebabkan loop retry tak terbatas pada kegagalan persisten.

T: Apa yang terjadi ketika Celery worker crash di tengah tugas?

Perilaku tergantung pada pengaturan acks_late. Dengan acks_late=True, broker mengirimkan ulang pesan ke worker lain karena acknowledgment tidak pernah terkirim. Dengan default acks_late=False, pesan di-acknowledge sebelum eksekusi, jadi crash berarti tugas hilang. Sistem produksi yang menangani beban kerja kritis harus menggunakan acks_late=True dikombinasikan dengan desain tugas idempoten.

T: Jelaskan perbedaan antara .delay(), .apply_async(), dan memanggil tugas secara langsung.

.delay(*args) adalah syntactic sugar untuk .apply_async(args=args). .apply_async() menerima opsi tambahan seperti countdown, eta, queue, priority, dan expires. Memanggil fungsi tugas secara langsung (tanpa .delay()) mengeksekusinya secara sinkron di proses saat ini — berguna untuk testing tetapi mengalahkan tujuan pemrosesan async.

T: Bagaimana caching layer berinteraksi dengan hasil tugas Celery?

Hasil tugas yang disimpan di Celery result backend dapat di-cache menggunakan framework cache Django. View memeriksa cache terlebih dahulu; jika tidak ada, view mengirim tugas dan menyimpan ID AsyncResult. Request berikutnya melakukan polling ke result backend melalui ID yang di-cache sampai tugas selesai, lalu meng-cache output akhir.

Checklist Deployment Produksi

Men-deploy Celery bersama Django memerlukan perhatian pada beberapa masalah operasional yang juga diuji dalam wawancara.

# myproject/settings.py — Production configuration
CELERY_TASK_ALWAYS_EAGER = False  # Never True in production
CELERY_TASK_ACKS_LATE = True  # Redelivery on worker crash
CELERY_WORKER_PREFETCH_MULTIPLIER = 1  # Fair scheduling
CELERY_TASK_REJECT_ON_WORKER_LOST = True  # Reject on unexpected exit
CELERY_TASK_TIME_LIMIT = 300  # Hard kill after 5 minutes
CELERY_TASK_SOFT_TIME_LIMIT = 240  # SoftTimeLimitExceeded after 4 min
CELERY_WORKER_MAX_TASKS_PER_CHILD = 1000  # Prevent memory leaks
CELERY_BROKER_CONNECTION_RETRY_ON_STARTUP = True

Pengaturan WORKER_MAX_TASKS_PER_CHILD memulai ulang proses worker setelah 1000 tugas, mencegah kebocoran memori — perbaikan yang ditangani Celery 5.6 secara lebih luas dengan patch kebocoran memorinya.

Manajemen proses dengan systemd atau supervisor memastikan worker restart pada kegagalan. Unit systemd minimal:

# /etc/systemd/system/celery-worker.service
[Unit]
Description=Celery Worker
After=network.target redis.service

[Service]
Type=forking
User=django
Group=django
WorkingDirectory=/opt/myproject
ExecStart=/opt/myproject/venv/bin/celery -A myproject worker \
    --loglevel=info --concurrency=4 --pidfile=/var/run/celery/worker.pid
ExecStop=/bin/kill -s TERM $MAINPID
Restart=always

[Install]
WantedBy=multi-user.target

Kesimpulan

• Celery 5.6.3 (Maret 2026) membawa perbaikan kebocoran memori, structured logging, dukungan quorum queue, dan kompatibilitas psycopg3 — upgrade dari versi lama untuk mendapat manfaat segera.
• Selalu kirim primary key ke tugas, jangan pernah objek ORM. Ini mencegah kesalahan serialisasi dan data basi.
• Rutekan tugas ke antrian khusus berdasarkan karakteristik beban kerja. Notifikasi cepat dan laporan lambat tidak boleh bersaing untuk worker yang sama.
• Gunakan acks_late=True dan desain tugas idempoten untuk beban kerja kritis yang harus bertahan dari crash worker.
• Tetapkan time_limit dan soft_time_limit pada setiap tugas untuk mencegah worker yang menggantung dari mengonsumsi sumber daya tanpa batas.
• Framework tugas bawaan Django 6.0 menangani pekerjaan latar belakang sederhana; Celery tetap diperlukan untuk pemrosesan terdistribusi, penjadwalan, dan canvas workflows.
• Pantau kedalaman antrian dan tingkat retry dengan Flower atau agregasi log terstruktur untuk mendeteksi masalah kapasitas sebelum memengaruhi pengguna.