Worker Spekulatif: Pola Rollback Transaksi & Konsistensi Data

Sistem pemrosesan latar belakang (background worker) throughput tinggi yang mengandalkan penguncian pesimistis—seperti SELECT FOR UPDATE pada database relasional atau Redis distributed lock (Redlock)—kerap menghadapi lock contention parah. Saat ratusan worker memperebutkan entitas data yang sama, latensi antrean meningkat eksponensial akibat waktu tunggu lock (lock acquisition wait time), head-of-line blocking, dan risiko deadlock. Pola Worker Spekulatif mengeliminasi distributed lock eksklusif di awal proses dengan mengadopsi model eksekusi optimistik: task dijalankan langsung di atas snapshot data, mencatat log kompensasi lokal, dan memvalidasi keabsahan mutasi menggunakan operasi Compare-And-Swap (CAS) atomik pada fase commit.

Bottleneck Distributed Lock pada Beban Konkurensi Tinggi

Pola locking konvensional mengasumsikan konflik sering terjadi sehingga mengunci resource sebelum proses dimulai:

1. AcquireLock(resource_id, TTL)
2. Read state dari database
3. Eksekusi kalkulasi bisnis (I/O, komputasi CPU)
4. Mutasi state dan write back ke database
5. ReleaseLock(resource_id)

Pendekatan ini memicu degradasi performa terukur pada beban tinggi:

• Tail Latency Membengkak: Jika eksekusi task memerlukan waktu 50 ms dan terdapat 20 worker mengantre untuk entitas yang sama, worker terakhir menunggu minimal 1.000 ms murni untuk akuisisi lock.
• Network Round-Trip Overhead: Lock terdistribusi berbasis Redis atau etcd membutuhkan minimal 2 RTT (Acquire dan Release), rentan terhadap jitter jaringan dan potensi lock leak jika worker mati mendadak sebelum TTL habis.
• Underutilization Komputasi: CPU worker terhenti dalam kondisi idle wait atau polling sleep alih-alih mengeksekusi payload.

Arsitektur Worker Spekulatif

Pola ini terinspirasi dari model efek transaksional pada bahasa pemrograman Verse (konsep failure-directed control flow) serta Software Transactional Memory (STM). Task dieksekusi dengan asumsi bahwa state tidak berubah selama komputasi berlangsung.

Siklus hidup worker spekulatif terbagi menjadi tiga fase terisolasi:

1. Speculative Execution: Worker membaca snapshot state saat ini beserta atribut versi (version counter). Worker mengeksekusi aturan bisnis. Jika ada mutasi parsial pada storage perantara atau I/O pihak ketiga, worker mencatat aksi balik (inverse action) ke dalam Compensation Log.
2. Atomic Validation & Commit (CAS): Worker mencoba melakukan atomic commit. Validasi dilakukan melalui CAS pada database: UPDATE table SET state = new_state, version = version + 1 WHERE id = target_id AND version = snapshot_version.
3. Resolution (Abort vs. Complete): Jika query CAS mengembalikan rows affected = 1, commit berhasil. Jika rows affected = 0, telah terjadi konflik state (invarian terlanggar). Worker memicu proses Abort: mengeksekusi Compensation Log secara terbalik (LIFO) untuk mengembalikan efek samping parsial, lalu melakukan penjadwalan ulang task (retry).

Implementasi Worker Pool dan Compensation Log di Go

Berikut implementasi konkret worker pool spekulatif dengan memory-backed store, versioning atomik, dan compensation log stack.

package main

import (
	"context"
	"errors"
	"fmt"
	"sync"
	"sync/atomic"
	"time"
)

type Account struct {
	Balance int64
	Version uint64
}

type Store struct {
	mu   sync.RWMutex
	data map[string]*Account
}

func (s *Store) Get(id string) (Account, error) {
	s.mu.RLock()
	defer s.mu.RUnlock()
	acc, ok := s.data[id]
	if !ok {
		return Account{}, errors.New("account not found")
	}
	return *acc, nil
}

func (s *Store) CommitCAS(id string, expectedVersion uint64, newBalance int64) bool {
	s.mu.Lock()
	defer s.mu.Unlock()
	acc, ok := s.data[id]
	if !ok || acc.Version != expectedVersion {
		return false
	}
	acc.Balance = newBalance
	acc.Version++
	return true
}

type CompensationFunc func(ctx context.Context) error

type SpeculativeContext struct {
	undoStack []CompensationFunc
}

func (sc *SpeculativeContext) RegisterRollback(fn CompensationFunc) {
	sc.undoStack = append(sc.undoStack, fn)
}

func (sc *SpeculativeContext) Rollback(ctx context.Context) {
	// Jalankan secara LIFO
	for i := len(sc.undoStack) - 1; i >= 0; i-- {
		_ = sc.undoStack[i](ctx)
	}
	sc.undoStack = nil
}

type TransferTask struct {
	AccountID string
	Amount    int64
	MaxRetry  int
}

func ExecuteSpeculativeTask(ctx context.Context, store *Store, task TransferTask) error {
	for attempt := 1; attempt <= task.MaxRetry; attempt++ {
		sCtx := &SpeculativeContext{}

		// 1. Snapshot Read
		snapshot, err := store.Get(task.AccountID)
		if err != nil {
			return err
		}

		// 2. Speculative Execution & Invariant Check
		newBalance := snapshot.Balance + task.Amount
		if newBalance < 0 {
			return errors.New("invariant violation: insufficient funds")
		}

		// Contoh simulasi efek samping eksternal (misal reservasi kuota di Redis)
		// Simpan operasi rollback-nya ke stack kompensasi
		sCtx.RegisterRollback(func(ctx context.Context) error {
			// ponytail: logging kegagalan kompensasi ke metrics sistem diabaikan untuk simplifikasi
			return nil
		})

		// 3. Atomic Commit
		success := store.CommitCAS(task.AccountID, snapshot.Version, newBalance)
		if success {
			return nil // Transaksi berhasil
		}

		// 4. Abort & Rollback jika CAS bentrok
		sCtx.Rollback(ctx)

		// Exponential backoff sebelum retry
		time.Sleep(time.Duration(attempt*5) * time.Millisecond)
	}
	return errors.New("task aborted: max retries reached due to contention")
}

Catatan arsitektur: Stack kompensasi hanya menangani mutasi eksternal atau buffer temporer (misal: reservasi cache, alokasi kuota pesan). State database inti tidak memerlukan undo log manual karena isolasi transaksi atomik CAS secara inheren menolak penulisan jika versi tidak cocok.

Trade-off Operasional: CPU Cost vs. Latensi Antrean

Model eksekusi spekulatif menukar siklus CPU untuk memangkas latensi latensi antrean. Evaluasi trade-off harus didasarkan pada karakteristik beban kerja:

Metrik Utama: Abort Rate

Metrik primer penentu kesehatan arsitektur spekulatif adalah Abort Rate:

Abort Rate = (Total Aborted Attempts / Total Task Executions) * 100%

• Abort Rate < 10%: Kondisi optimal. Worker spekulatif memberikan throughput jauh melampaui distributed lock.
• Abort Rate 10% - 25%: Masih dapat diterima jika biaya komputasi task rendah (< 10 ms).
• Abort Rate > 30%: Kondisi kritis. Fenomena livelock dan pemborosan resource CPU terjadi karena sistem berulang kali membuang hasil kerja.

Strategi Dead-Letter Queue (DLQ) dan Routing Adaptif

Ketika contention mencapai titik ekstrem pada entitas tertentu (misal: flash sale pada satu ID inventaris), retry spekulatif murni akan menyebabkan starvation. Terapkan strategi dua lapis:

1. Jittered Truncated Exponential Backoff: Tambahkan entropi acak pada durasi backoff untuk memecah formasi worker yang mengeksekusi CAS secara simultan pasca-abort: t_wait = min(max_wait, base * 2^attempt) + rand(0, jitter).
2. Adaptive Fallback & DLQ Routing: Jika task melampaui batas toleransi MaxRetry (misal: 3–5 kali gagal CAS), jangan langsung membuang task. Rutekan task ke Serial Quarantine Queue atau Dead-Letter Queue (DLQ) berbobot penguncian pesimistis. Worker pada antrean ini mengeksekusi task secara serial menggunakan lock eksklusif untuk menjamin kepastian eksekusi tanpa membebani pool spekulatif utama.