Desain Microservices Berbasis Event-Driven untuk Sistem Checkout E-Commerce

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap e-commerce skala enterprise, arsitektur monolitik tradisional sering kali menjadi hambatan utama ketika menghadapi lonjakan transaksi (high concurrency), seperti saat kampanye flash sale 11.11 atau Black Friday. Pada sistem monolitik, layanan pemesanan (checkout), manajemen inventaris, pemrosesan pembayaran pihak ketiga (gateway), dan penjadwalan pengiriman berjalan dalam satu basis kode dan basis data terpusat (biasanya MySQL/MariaDB). Ketika ribuan pengguna menekan tombol "Bayar" secara bersamaan, terjadi perebutan sumber daya (database locking, koneksi pool exhaustion, thread blocking), yang berujung pada timeout, kegagalan transaksi massal, dan rusaknya pengalaman pengguna.

Bottleneck performa utama dalam sistem checkout monolitik meliputi:

• Database Lock Contention: Tabel inventaris dan saldo pengguna mengalami deadlock karena transaksi ACID ketat dipaksa berjalan secara sinkron.
• Ketergantungan Eksternal (Third-Party Latency): Gateway pembayaran eksternal sering kali merespons lambat (2-5 detik). Jika proses ini sinkron, thread worker web server (seperti PHP-FPM atau Node.js event loop) akan tertahan (blocking), melumpuhkan seluruh kapasitas server.
• Kurangnya Ketahanan (Resilience): Kegagalan pada satu modul (misalnya layanan kurir pihak ketiga sedang down) menyebabkan seluruh alur checkout gagal total.

Untuk mengatasi masalah ini, evolusi menuju Event-Driven Microservices Architecture (EDMA) dengan pendekatan asinkron menjadi keharusan mutlak. Dengan memisahkan layanan menggunakan message broker (seperti Apache Kafka), setiap domain (Checkout, Inventory, Payment, Shipping) beroperasi secara otonom, berkomunikasi melalui event bukan panggilan HTTP langsung, serta menerapkan pola transaksi terdistribusi seperti Saga Pattern dan validasi Idempotency Key.

Kondisi Sebelum vs Sesudah Penerapan

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur Event-Driven untuk sistem checkout mengandalkan pertukaran event (kejadian masa lalu yang tidak dapat diubah) di mana produsen mempublikasikan event ke Kafka topic, dan konsumen (consumers) secara asinkron memproses event tersebut.

Alur Kerja (Workflow) End-to-End Sistem Checkout

[Client / Browser] 
       │ (HTTPS / POST /checkout)
       ▼
[API Gateway / Nginx] 
       │ 
       ▼
[Checkout Service (Go/PHP)] ──(Tulis status Pending)──> [(MySQL DB)]
       │
       ├─────────────────── Publishes ───────────────────>
       ▼                                                 ▼
[Apache Kafka]                                    [Kafka Topic: checkout-initiated]
       │                                                 │
       ├───────────────────────┬─────────────────────────┘
       │                       │
       ▼                       ▼
[Inventory Service]     [Payment Service]
(Kurangi Stok Redis)    (Inisiasi Gateway)
       │                       │
       ├─(Success)             ├─(Success)
       ▼                       ▼
[Kafka: inventory-res]  [Kafka: payment-success]
       │                       │
       └───────────┬───────────┘
                   ▼
         [Orchestrator / Saga Saga Manager]
                   │
                   ▼
         [Shipping Service]
         (Buat Waybill Kurir)

Penjelasan alur di balik layar:

1. Inisiasi: Klien mengirimkan payload checkout ke API Gateway yang dilindungi WAF (ModSecurity/Cloudflare). Permintaan diteruskan ke Checkout Service.
2. Penyimpanan Lokal & Publikasi Event: Checkout Service membuat entri pesanan dengan status PENDING di database lokal, lalu mempublikasikan event CheckoutInitiated ke Apache Kafka dengan menyertakan unik Idempotency-Key.
3. Pemrosesan Paralel Asinkron:
   • Inventory Service menerima event, memvalidasi stok di Redis/MySQL, dan mengurangi stok secara atomik.
   • Payment Service menerima event, menghubungi gateway pembayaran eksternal secara asinkron.
4. Kompensasi Saga: Jika salah satu layanan gagal (misalnya pembayaran ditolak), saga orchestrator memicu event kompensasi (CancelInventoryReservation) untuk mengembalikan stok.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun sistem checkout terdistribusi, terdapat dua pendekatan utama dalam koordinasi Saga: Orchestration-based Saga vs Choreography-based Saga.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengimplementasikan kode, pastikan infrastruktur server (Ubuntu 22.04 LTS / Debian 12) memenuhi spesifikasi enterprise:

• CPU/RAM: Minimal 4 vCPU, 8GB RAM untuk node Kafka & Database; 2 vCPU, 4GB RAM untuk microservices.
• Software Stack:
  • Nginx (Reverse Proxy & SSL Termination)
  • Apache Kafka & Apache ZooKeeper / KRaft mode
  • Redis Enterprise / Redis Cluster (untuk Idempotency Cache & Caching Stok)
  • MySQL 8.0 / MariaDB 10.11 (Transactional Storage)
  • Go 1.22+ / PHP 8.3 (FPM) / Node.js 20 LTS
• Keamanan: Fail2ban terkonfigurasi, UFW firewall aktif, SSL/TLS Let's Encrypt dengan cipher modern.

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi Apache Kafka (Broker Messaging)

Buat file konfigurasi /opt/kafka/config/server.properties untuk production cluster:

broker.id=1
listeners=PLAINTEXT://0.9.0.0:9092,EXTERNAL://0.0.0.0:9093
advertised.listeners=PLAINTEXT://kafka-broker-1.internal:9092,EXTERNAL://checkout.enterprise.com:9093
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/var/lib/kafka/data
num.partitions=6
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
default.replication.factor=3
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=zk1.internal:2181,zk2.internal:2181,zk3.internal:2181
zookeeper.connection.timeout.ms=18000

Langkah 2: Skema Database Transaksional & Idempotency Key (MySQL)

CREATE DATABASE IF NOT EXISTS checkout_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE checkout_db;

CREATE TABLE IF NOT EXISTS orders (
    order_id VARCHAR(36) PRIMARY KEY,
    user_id BIGINT UNSIGNED NOT NULL,
    total_amount DECIMAL(12, 2) NOT NULL,
    status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_user_status (user_id, status)
) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS idempotency_keys (
    idempotency_key VARCHAR(64) PRIMARY KEY,
    order_id VARCHAR(36) NOT NULL,
    response_payload JSON NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_created (created_at)
) ENGINE=InnoDB;

Langkah 3: Implementasi Checkout Service dengan Go & Idempotency

Buat file main.go untuk menangani permintaan checkout dengan proteksi Idempotency Key dan pengiriman event Kafka:

package main

import (
	"database/sql"
	"encoding/json"
	"fmt"
	"log"
	"net/http"

	_ "github.com/go-sql-driver/mysql"
	"github.com/google/uuid"
	"github.com/segmentio/kafka-go"
)

type CheckoutRequest struct {
	UserID      uint64  `json:"user_id"`
	TotalAmount float64 `json:"total_amount"`
}

type CheckoutResponse struct {
	OrderID string `json:"order_id"`
	Status  string `json:"status"`
}

var db *sql.DB
var kafkaWriter *kafka.Writer

func init() {
	var err error
	db, err = sql.Open("mysql", "root:SecurePassword123@tcp(127.0.0.1:3306)/checkout_db?parseTime=true")
	if err != nil {
		log.Fatalf("Failed to connect to database: %v", err)
	}

	kafkaWriter = &kafka.Writer{
		Addr:     kafka.TCP("127.0.0.1:9092"),
		Topic:    "checkout-initiated",
		Balancer: &kafka.Hash{},
	}
}

func handleCheckout(w http.ResponseWriter, r *http.Request) {
	if r.Method != http.MethodPost {
		http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
		return
	}

	idempotencyKey := r.Header.Get("X-Idempotency-Key")
	if idempotencyKey == "" {
		http.Error(w, "Missing X-Idempotency-Key header", http.StatusBadRequest)
		return
	}

	// Cek apakah Idempotency Key sudah pernah diproses
	var existingOrderID string
	var existingResponseJSON []byte
	err := db.QueryRow("SELECT order_id, response_payload FROM idempotency_keys WHERE idempotency_key = ?", idempotencyKey).Scan(&existingOrderID, &existingResponseJSON)
	if err == nil {
		// Return cached response
		w.Header().Set("Content-Type", "application/json")
		w.WriteHeader(http.StatusOK)
		w.Write(existingResponseJSON)
		return
	}

	var req CheckoutRequest
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}

	orderID := uuid.New().String()
	
	// Transaksi Database Lokal
	tx, err := db.Begin()
	if err != nil {
		http.Error(w, "Database error", http.StatusInternalServerError)
		return
	}
	defer tx.Rollback()

	_, err = tx.Exec("INSERT INTO orders (order_id, user_id, total_amount, status) VALUES (?, ?, ?, ?)", orderID, req.UserID, req.TotalAmount, "PENDING")
	if err != nil {
		http.Error(w, "Failed to create order", http.StatusInternalServerError)
		return
	}

	respObj := CheckoutResponse{OrderID: orderID, Status: "PENDING"}
	respBytes, _ := json.Marshal(respObj)

	_, err = tx.Exec("INSERT INTO idempotency_keys (idempotency_key, order_id, response_payload) VALUES (?, ?, ?)", idempotencyKey, orderID, string(respBytes))
	if err != nil {
		http.Error(w, "Idempotency violation or DB error", http.StatusInternalServerError)
		return
	}

	if err := tx.Commit(); err != nil {
		http.Error(w, "Commit failed", http.StatusInternalServerError)
		return
	}

	// Publikasi Event ke Kafka
	err = kafkaWriter.WriteMessages(r.Context(), kafka.Message{
		Key:   []byte(orderID),
		Value: respBytes,
	})
	if err != nil {
		log.Printf("Failed to publish kafka event: %v", err)
	}

	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusAccepted)
	w.Write(respBytes)
}

func main() {
	http.HandleFunc("/api/v1/checkout", handleCheckout)
	log.Println("Checkout Microservice running on port 8080...")
	log.Fatal(http.ListenAndServe(":8080", nil))
}

6. Bedah Kode & Penjelasan Detail Baris Kunci

1. X-Idempotency-Key Validation: Baris r.Header.Get("X-Idempotency-Key") memastikan bahwa setiap permintaan pembayaran memiliki tanda tangan unik. Jika pengguna menekan tombol "Bayar" dua kali akibat jaringan terputus, sistem mendeteksi key yang sama dan langsung mengembalikan respons cache tanpa memotong saldo dua kali.
2. Database Transaction (db.Begin() & tx.Commit()): Memastikan atomisitas penyimpanan entri pesanan dan pencatatan idempotency key. Gagal di satu sisi akan memicu rollback total.
3. Kafka Hash Balancer (Balancer: &kafka.Hash{}): Menggunakan order_id sebagai message key menjamin bahwa semua event yang berkaitan dengan pesanan yang sama akan masuk ke partisi Kafka yang sama, menjaga urutan pemrosesan secara kronologis (ordered processing).

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!IMPORTANT] Pada lingkungan produksi dengan beban mencapai 50.000 TPS, kegagalan koneksi Redis atau Kafka dapat memicu efek cascading. Pastikan untuk menerapkan connection pooling yang ketat serta konfigurasi backpressure pada consumer Kafka.

Kasus: Flash Sale 100.000 Item dalam 5 Detik

• Strategi:
  1. Stok divalidasi dan dikurangi secara in-memory menggunakan Redis Lua Script untuk menjamin atomisitas sebelum event dikirim ke Kafka.
  2. Nginx dikonfigurasi sebagai Reverse Proxy dengan batasan rate-limiting per IP (limit_req_zone) guna mencegah serangan botnet/scalper.
  3. Kafka Consumers dijalankan dalam jumlah instance pod Kubernetes yang selaras dengan jumlah partisi Kafka (6 partisi = 6 pod worker aktif).

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Mengabaikan Idempotency pada Kafka Consumer. Masalah: Kafka menggunakan mekanisme at-least-once delivery, yang berarti sebuah event dapat dikirim dua kali jika terjadi rebalancing cluster. Solusi: Pastikan setiap consumer mengimplementasikan pengecekan status di database atau menggunakan Redis SETNX dengan TTL sebelum memproses event pembayaran.
• Anti-Pattern 2: Sinkronisasi Berlebihan dalam Saga. Masalah: Menunggu respons HTTP sinkron dari layanan inventaris dan pembayaran di dalam API checkout. Solusi: Gunakan sepenuhnya asynchronous messaging dan kembalikan status 202 Accepted kepada klien.

9. Benchmark, Metrik Kinerja & Tuning Performa

Lakukan pengujian beban (load testing) menggunakan k6 untuk menguji endpoint checkout:

import http from 'k6/http';
import { check, sleep } from 'k6';
import { uuidv4 } from 'https://jslib.k6.io/k6-utils/1.4.0/index.js';

export const options = {
  stages: [
    { duration: '30s', target: 500 },
    { duration: '1m', target: 2000 },
    { duration: '30s', target: 0 },
  ],
};

export default function () {
  const url = 'http://localhost:8080/api/v1/checkout';
  const payload = JSON.stringify({
    user_id: Math.floor(Math.random() * 100000) + 1,
    total_amount: 150.00,
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
      'X-Idempotency-Key': uuidv4(),
    },
  };

  const res = http.post(url, payload, params);
  check(res, {
    'status is 202': (r) => r.status === 202,
    'response time < 50ms': (r) => r.timings.duration < 50,
  });
  sleep(0.1);
}

Hasil Tuning Linux Kernel (/etc/sysctl.conf):

fs.file-max = 2097152
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535

10. Checklist Penerapan Produksi & Kesimpulan

• Konfigurasi Kafka dengan replikasi minimal 3 untuk mencegah data loss.
• Validasi Idempotency Key di setiap lapisan entry point pembayaran.
• Implementasi Distributed Tracing (OpenTelemetry + Jaeger) untuk memantau perjalanan event lintas microservices.
• Pengaturan Dead Letter Queue (DLQ) untuk event yang gagal diproses setelah 3 kali retry.
• Pengujian Chaos Engineering (mematikan Kafka broker atau Database secara acak saat load test).

Dengan menerapkan arsitektur Event-Driven dan pola Saga serta Idempotency yang kokoh, sistem e-commerce checkout Anda kini siap menembus batas skalabilitas enterprise modern dengan ketersediaan tinggi (high availability) dan integritas data finansial yang mutlak.