Belajar Solution Architect - Integration Architecture

#Pendahuluan

Setelah di episode 5 kalian bisa menurunkan keputusan arsitektur menjadi desain fisik di cloud — VPC multi-AZ, managed database, autoscaling — solusi kalian sudah berdiri. Tetapi tidak ada solusi modern yang berdiri sendiri: ia harus bicara dengan payment gateway, CRM, sistem legacy, layanan pihak ketiga, dan aplikasi internal lain. Integration architecture adalah disiplin merancang percakapan itu.

Mengapa ini krusial? Karena integrasi adalah sumber mayoritas kegagalan lintas sistem: partner timeout saat checkout, pesan duplikat menghasilkan double payment, skema API partner berubah tanpa pemberitahuan, atau batch malam yang tumpang tindih dengan jam ramai. Desain integrasi yang baik mengantisipasi semua itu sejak awal.

#Keputusan Fundamental: Sinkron vs Asinkron

Percakapan antar-sistem ada dua karakter, dan memilihnya salah adalah kesalahan arsitektur termahal:

Aturan praktis yang bisa kalian pegang:

• Pakai sinkron hanya jika pemanggil benar-benar butuh jawaban untuk melanjutkan (cek saldo sebelum bayar).
• Pakai asinkron untuk semua yang bisa ditunda beberapa detik/menit (kirim email, generate invoice, update search index).

Studi kasus tiket kita adalah contoh sempurna: pembelian kursi divalidasi sinkron, tetapi setelah pembayaran terkonfirmasi semuanya asinkron — penerbitan tiket QR, pengiriman email, sinkronisasi ke sistem panitia. Satu kegagalan email tidak boleh menggagalkan pembayaran.

#Event Streaming dan Message Broker

Untuk lapisan asinkron, kalian akan memilih antara dua keluarga teknologi:

• Message queue klasik (SQS, RabbitMQ, Azure Service Bus): pesan dikonsumsi sekali oleh satu consumer; cocok untuk distribusi pekerjaan.
• Event streaming (Kafka, Kinesis, Pub/Sub, Event Hubs): event tersimpan dalam log dan bisa dibaca banyak consumer secara independen, bahkan direplay; cocok untuk integrasi banyak sistem dan pipeline analitik (kita lanjutkan di episode 22).

Kriteria pemilihan cepat: satu tugas dikerjakan satu pihak → queue; satu kejadian diminati banyak pihak → streaming. Untuk studi kasus kita, topic payment.confirmed di Kafka/Pub/Sub melayani tiga consumer sekaligus — itulah nilai fan-out streaming.

#Idempotency: Pelajaran Paling Penting

Sistem asinkron menjamin at-least-once delivery — artinya pesan yang sama bisa diproses dua kali. Konsekuensinya wajib: setiap handler harus aman terhadap duplikat (idempotent). Cara standarnya dengan idempotency key:

1. Terima pesan event_id = pay_20260816_000123.
2. Cek tabel processed_events: apakah event_id sudah ada?
   -> ya  : skip (log duplicate), commit offset/ack.
   -> no  : proses penerbitan tiket,
            INSERT event_id + hasil ke processed_events DALAM SATU TRANSAKSI,
            lalu ack.

Tanpa pola ini, satu retry jaringan menghasilkan dua e-tiket untuk satu pembayaran — insiden yang sangat umum di production. Catatan penting: cek-dan-catat harus atomik; kalau dilakukan sebagai dua langkah terpisah masih ada celah race condition.

#Kontrak API yang Tahan Lama

API adalah perjanjian antar tim — dan seperti perjanjian, ia perlu dirancang untuk bertahan:

• Versioning sejak hari pertama: /v1/orders, bukan /orders yang nanti diam-diam berubah. Versi lama diberi masa deprecasi jelas.
• Backward compatibility: tambah field opsional boleh tanpa versi baru; hapus/ganti makna field = versi baru.
• Schema-first: definisikan kontrak di OpenAPI/protobuf, generate server stub dan client SDK darinya. Diskusi integrasi jadi objektif karena semua merujuk artefak yang sama.
• Error contract konsisten: struktur error seragam (kode mesin-membaca + pesan manusia), plus status HTTP yang jujur.
• Rate limiting & SLA eksplisit: berapa request/detik yang dijamin, apa yang terjadi saat melebihi (429 dengan header Retry-After).

Contoh potongan kontrak OpenAPI yang menunjukkan versioning dan error contract:

paths:
  /v1/orders:
    post:
      summary: Buat pesanan tiket
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/CreateOrderRequest"
      responses:
        "201":
          description: Pesanan dibuat, status PENDING_PAYMENT
        "409":
          description: Kursi sudah terkunci pembeli lain
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
        "429":
          description: Melebihi rate limit
          headers:
            Retry-After:
              description: Detik sebelum boleh mencoba lagi
              schema:
                type: integer

#Batch, ETL, dan Pola Integrasi Legacy

Tidak semua integrasi real-time. Dua pola warisan yang masih dominan di enterprise:

• Batch/ETL — ekstraksi terjadwal (malam hari), transformasi, muat ke tujuan. Masih tepat untuk reporting dan sinkronisasi data besar yang tidak sensitif waktu. Tren modern bergeser ke ELT: muat mentah dulu ke data warehouse, transformasi belakangan dengan SQL (dibahas di episode 22).
• File-based/API legacy — sistem lawas yang hanya bisa CSV/SOAP. Bungkus dengan integration layer (gateway/adaptor) supaya keanehan legacy tidak bocor ke sistem baru.

Pola enterprise lain yang wajib kenal:

#Common Pitfalls

• Chained synchronous calls — A memanggil B memanggil C memanggil D; satu lambat, semua lambat. Solusi: putus rantai dengan event pada titik yang tidak butuh jawaban langsung.
• Integrasi tanpa timeout/retry policy — panggilan tanpa timeout menggantung thread selamanya; retry tanpa backoff menjadikan storm saat partner pulih.
• Skema diam-diam berubah — partner menambah field dan parser kalian pecah. Mitigasi: tolerant reader (abaikan field tak dikenal) + contract test berkala.
• Mengabaikan jam dan zona waktu — batch window yang dihitung di UTC tapi dieksekusi server WIB menggeser data satu jam. Selalu sepakati timezone eksplisit.

#Penutup

Inti yang harus dibawa pulang:

• Sinkron untuk yang butuh jawaban sekarang; asinkron untuk sisanya — dan mayoritas workflow seharusnya asinkron.
• Queue untuk mendistribusikan pekerjaan, streaming untuk fan-out event ke banyak consumer dan replay.
• Idempotency bukan opsi: at-least-once delivery menjamin duplikat, tangani dengan idempotency key yang dicek atomik.
• Kontrak API dirancang untuk bertahan: versioning, backward compatible, schema-first, error dan rate limit eksplisit.
• Pola enterprise (circuit breaker, saga, outbox, DLQ) adalah jawaban siap-pakai untuk masalah yang pasti datang.

Di episode 7 selanjutnya kita akan membahas data solution design — memilih storage yang tepat untuk tiap kebutuhan (relational, NoSQL, warehouse, object storage), merancang data platform end-to-end, dan strategi modeling yang membuat data kalian tetap sehat saat volume membesar. Sampai jumpa di episode 7!