event-driven-architect

name	event-driven-architect
description	Expert guide for microservices, message queues, Event Sourcing, and high-scale backend architectures / Panduan ahli untuk arsitektur microservices, antrean pesan, dan backend skala tinggi.
author	Roedy Rustam

Event-Driven Architecture Expert

English | Bahasa Indonesia

---

English

Description

This skill provides architectural guidance for breaking down large monolithic applications into scalable, decoupled services. It focuses on Event-Driven Architecture (EDA), message brokers, and advanced patterns like Event Sourcing and CQRS (Command Query Responsibility Segregation).

Trigger Conditions

• Scaling a system that handles extremely high throughput or traffic spikes.
• Implementing background jobs, asynchronous workers, or heavy data processing.
• Transitioning from a monolith to microservices.
• Integrating message brokers like RabbitMQ, Apache Kafka, AWS SQS, or Redis Pub/Sub.
• Resolving distributed transaction issues (e.g., handling the Saga pattern).

Core Architecture Guidelines

1. Decoupling via Events

Do not use synchronous HTTP calls between microservices for state mutations. It creates tightly coupled systems that fail in cascades.

• Publisher/Subscriber: When Service A does something, it publishes an event (e.g., UserCreated). Service B and Service C listen to this event and react asynchronously.
• Use RabbitMQ or AWS SQS for standard task queues (where order and exact-once delivery might be managed).
• Use Apache Kafka or Redpanda for high-throughput event streaming where logs need to be replayed.

2. The Saga Pattern (Distributed Transactions)

In microservices, you cannot use simple database transactions (ACID) across different databases.

• Use the Saga Pattern to coordinate multiple operations. If Step 3 in a 4-step process fails, the system must publish "compensating events" to undo Steps 1 and 2 in the other services.

3. CQRS (Command Query Responsibility Segregation)

For high-read applications (like social media or analytics dashboards), split the read operations from the write operations.

• Commands: Mutate state (write database).
• Queries: Read state (read replica or materialized views/Elasticsearch).
• Events synchronize the Write DB with the Read DB.

4. Event Sourcing

Instead of storing just the current state of an entity (e.g., AccountBalance = $100), store the history of events that led to that state (Deposited $150, Withdrew $50). The current state is derived by replaying the events. This is mandatory for financial and highly auditable systems.

---

Bahasa Indonesia

Deskripsi

Skill ini memberikan panduan arsitektural untuk memecah aplikasi monolit yang besar menjadi layanan yang terdesentralisasi (decoupled) dan dapat diskalakan. Fokus utamanya adalah pada Event-Driven Architecture (Arsitektur Berbasis Peristiwa), message brokers (pialang pesan), serta pola lanjutan seperti Event Sourcing dan CQRS (Command Query Responsibility Segregation).

Kondisi Pemicu

• Menskalakan sistem untuk menangani lonjakan traffic atau volume data yang sangat tinggi.
• Mengimplementasikan pekerjaan latar belakang (background jobs), worker asinkron, atau pemrosesan data berat.
• Bertransisi dari arsitektur monolit ke layanan mikro (microservices).
• Mengintegrasikan message brokers seperti RabbitMQ, Apache Kafka, AWS SQS, atau Redis Pub/Sub.
• Menyelesaikan masalah transaksi terdistribusi (misalnya menerapkan pola Saga).

Panduan Arsitektur Inti

1. Desentralisasi melalui Event

Jangan gunakan panggilan HTTP yang sinkron antar microservices untuk memutasi data. Hal ini menciptakan sistem yang saling bergantung ketat (tightly coupled) dan bisa menyebabkan kegagalan beruntun (cascading failures).

• Publisher/Subscriber: Saat Layanan A melakukan sesuatu, ia menerbitkan sebuah event (misalnya UserCreated). Layanan B dan C akan mendengarkan event ini dan bereaksi secara asinkron.
• Gunakan RabbitMQ atau AWS SQS untuk antrean tugas standar.
• Gunakan Apache Kafka atau Redpanda untuk streaming event throughput tinggi yang memerlukan replay log.

2. Pola Saga (Transaksi Terdistribusi)

Dalam arsitektur microservices, Anda tidak dapat menggunakan transaksi database ACID standar lintas database yang berbeda.

• Gunakan Saga Pattern untuk mengoordinasikan beberapa operasi. Jika Langkah 3 dalam proses 4-langkah gagal, sistem harus menerbitkan "event kompensasi" (pembatalan) untuk membatalkan Langkah 1 dan 2 pada layanan sebelumnya.

3. CQRS (Command Query Responsibility Segregation)

Untuk aplikasi dengan tingkat pembacaan yang sangat tinggi (seperti dasbor analitik), pisahkan operasi baca dari operasi tulis.

• Command: Memutasi state/data (Database Tulis).
• Query: Membaca state (Read Replica, Materialized Views, atau Elasticsearch).
• Event bertugas menyinkronkan Database Tulis ke Database Baca di latar belakang.

4. Event Sourcing

Daripada hanya menyimpan kondisi terbaru sebuah data (mis. SaldoAkun = Rp1.000.000), simpan sejarah lengkap peristiwa yang mengarah ke saldo tersebut (Setor Rp1.500.000, Tarik Rp500.000). Kondisi saat ini diturunkan (dikalkulasi) dengan memutar ulang (replaying) event tersebut. Pola ini wajib untuk sistem finansial dan sistem yang membutuhkan jejak audit tingkat tinggi.