Pendahuluan: Menjawab langsung tantangan backpressure

Backpressure muncul ketika produksi job atau request melebihi kapasitas pemrosesan batch, message queue, atau worker pool. Solusi yang efektif pada Spring Boot harus mengatur cache Redis agar tetap menyajikan data valid, menjaga antrean melalui konfigurasi Spring Batch/AMQP, serta mengendalikan worker agar tidak overcommit. Artikel ini menguraikan pendekatan praktis dengan konfigurasi nyata agar sistem tetap akurat dan responsif.

Memahami sumber backpressure dalam pipeline Spring Boot

Backpressure bisa terjadi karena latensi downstream (database lambat, API eksternal), throttle rate yang terlalu tinggi, atau worker pool yang terlalu kecil untuk volume job. Langkah pertama adalah mengidentifikasi titik pengumpulan: apakah job menumpuk di Spring Batch JobLauncher, antrian AMQP, atau queue internal worker. Gunakan metrics seperti antrean aktif, rata-rata waktu eksekusi, dan jumlah retry untuk mengukur beban.

Contoh pendekatan: tambahkan MeterRegistry dari Micrometer untuk memantau ukuran antrean AMQP.

@Bean
public AmqpInboundChannelAdapter amqpAdapter(MessageListenerContainer container,
                                              MeterRegistry registry) {
    Gauge.builder("queue.pending", container::getQueueNames, names -> {
        // logika penghitungan manual jika perlu
        return container.getQueueNames().length;
    }).register(registry);
    // konfigurasi adapter
}

Gauge di atas memberi sinyal kapan antrean meningkat drastis, sehingga sistem bisa menurunkan laju produser atau menambah worker.

Merancang cache Redis yang responsif saat antrian menumpuk

Cache tetap penting untuk menghindari akses berulang ke sumber data saat queue overload. Strategi kunci:

  • Cache aside dengan TTL pendek. Saat job sedang tinggi, gunakan TTL agar data tidak menjadi stale dan memudahkan refresh saat backpressure reda.
  • Optimalkan cache fill. Gunakan CacheManager Spring bersama @Cacheable dan pastikan sync diaktifkan jika data berasal dari satu sumber tunggal.
  • Locking saat refresh. Untuk menghindari cache stampede, gunakan distributed lock (contohnya melalui Redisson). Jadi hanya satu worker yang memperbarui cache sementara yang lain menunggu.

Contoh implementasi sederhana menggunakan RedisTemplate:

public Optional<Data> getFromCache(String key) {
    return Optional.ofNullable(redisTemplate.opsForValue().get(key));
}

public void refreshCache(String key, Supplier<Data> loader) {
    RLock lock = redissonClient.getLock("lock:" + key);
    if (lock.tryLock()) {
        try {
            Data value = loader.get();
            redisTemplate.opsForValue().set(key, value, Duration.ofMinutes(2));
        } finally {
            lock.unlock();
        }
    }
}

Kombinasi TTL dan locking memastikan cache tidak stale sekaligus tidak menyebabkan beban berlebih untuk memperbarui data.

Menjaga queue dan worker pool terkontrol

Ketika menggunakan Spring Batch atau AMQP, pengaturan concurrency menentukan responsivitas:

  • Spring Batch: Gunakan TaskExecutor dengan batas thread yang sesuai serta klausa throttleLimit pada step untuk membatasi jumlah job parallel.
  • AMQP: Atur prefetchCount dan jumlah consumer. Prefetch yang terlalu besar dapat menyebabkan worker mengambil lebih banyak pesan daripada yang bisa diselesaikan saat downstream lambat. Sesuaikan berdasarkan throughput rata-rata.
  • Worker pool: Gunakan ThreadPoolTaskExecutor dengan antrian bounded. Saat antrean penuh, request baru dapat ditolak atau di-backoff sehingga sistem tidak crash.
@Bean
public ThreadPoolTaskExecutor jobExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(4);
    executor.setMaxPoolSize(8);
    executor.setQueueCapacity(100);
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    return executor;
}

CallerRunsPolicy membuat thread pemanggil mengeksekusi job jika antrean penuh, mengurangi laju produksi secara otomatis.

Untuk AMQP consumer:

@Bean
public SimpleMessageListenerContainer listener(ConnectionFactory factory) {
    SimpleMessageListenerContainer container = new SimpleMessageListenerContainer(factory);
    container.setQueueNames("job-queue");
    container.setConcurrentConsumers(3);
    container.setPrefetchCount(5);
    return container;
}

Jumlah consumer dan prefetch harus disesuaikan dengan kapasitas downstream serta pemantauan berkelanjutan.

Strategi retry, idempotensi, observabilitas, dan mitigasi deadlock

Untuk menjaga konsistensi dan responsivitas saat backpressure:

  • Retry dan idempotensi. Balikkan job yang gagal ke queue dengan delay terukur atau gunakan RetryTemplate. Pastikan job idempoten agar retry tidak menyebabkan efek ganda.
  • Observabilitas. Catat metric queue depth, waktu eksekusi, dan status cache (hit/miss). Lengkapi log dengan trace identificator untuk menelusuri job.
  • Mitigasi deadlock/caching stale. Tetapkan batas waktu lock, pastikan renew lock saat job panjang, dan cek health cache untuk mendeteksi stale entry.

Contoh konfigurasi retry sederhana:

@Bean
public RetryTemplate retryTemplate() {
    RetryTemplate retry = new RetryTemplate();
    FixedBackOffPolicy backOff = new FixedBackOffPolicy();
    backOff.setBackOffPeriod(2000);
    retry.setBackOffPolicy(backOff);
    SimpleRetryPolicy policy = new SimpleRetryPolicy(3);
    retry.setRetryPolicy(policy);
    return retry;
}

Tambahkan log saat retry dimulai dan selesai agar bisa dilacak apakah job masuk loop reload atau tidak.

Terakhir, tetapkan health indicator untuk cache dan queue. Jika Redis mengalami latency tinggi atau queue backlog bertambah, sistem bisa beralih ke mode read-only atau menurunkan laju produser.

Kesimpulan

Mengendalikan cache, queue, dan worker Spring Boot saat mengalami backpressure membutuhkan kombinasi konfigurasi semantik dan observabilitas. Konfigurasi cache Redis dengan TTL dan distributed lock menjaga konsistensi data, sementara pengaturan worker pool dan AMQP mencegah sistem overwhelming. Tambahkan strategi retry/idempotensi, metric, dan mitigasi deadlock agar sistem tetap responsif walau volume job naik tajam.