System Integration #
Dalam dunia software engineering modern, hampir tidak ada sistem yang berdiri sendiri. Aplikasi web, mobile, backend service, third-party API, hingga sistem legacy saling terhubung untuk membentuk sebuah ekosistem. Proses menghubungkan berbagai sistem inilah yang disebut System Integration.
System integration bukan sekadar “API saling panggil”. Ia mencakup kontrak data, keamanan, reliability, observability, dan evolusi sistem jangka panjang. Kesalahan desain integrasi sering kali menjadi akar masalah: data tidak konsisten, sistem rapuh, sulit diskalakan, dan rawan security issue.
Artikel ini membahas:
- Apa itu system integration
- Jenis-jenis system integration
- Pola integrasi yang umum digunakan
- Best practice krusial (auth, pertukaran data, integrity check, dll)
- Contoh kasus dunia nyata
Apa Itu System Integration? #
System Integration adalah proses menghubungkan dua atau lebih sistem/aplikasi agar dapat:
- Bertukar data
- Berkolaborasi menjalankan proses bisnis
- Beroperasi sebagai satu kesatuan logis
Integrasi bisa terjadi antara:
- Internal service (microservices, modular monolith)
- External system (payment gateway, identity provider)
- Legacy system ↔ modern system
Tujuan utamanya:
- Menghindari data silo
- Meningkatkan automation
- Mempercepat business flow
- Mengurangi manual intervention
Jenis-Jenis System Integration #
Point-to-Point Integration #
Setiap sistem terhubung langsung ke sistem lain.
Karakteristik:
- Simple di awal
- Cepat diimplementasikan
Masalah:
- Sulit di-maintain
- Tight coupling
- Scaling nightmare (N sistem → N² koneksi)
Cocok untuk:
- Sistem kecil
- Integrasi sementara
API-Based Integration #
Integrasi melalui REST/gRPC/GraphQL API.
Karakteristik:
- Loose coupling
- Standar komunikasi jelas
- Mudah dikembangkan
Contoh:
- Mobile app ↔ Backend API
- Backend ↔ Third-party service
Catatan penting:
API bukan hanya endpoint, tapi kontrak
Event-Driven Integration #
Sistem berkomunikasi melalui event (asynchronous).
Teknologi umum:
- Kafka
- RabbitMQ
- AWS SNS/SQS
- GCP Pub/Sub
Kelebihan:
- Highly decoupled
- Scalable
- Resilient
Kekurangan:
- Debugging lebih kompleks
- Eventual consistency
File-Based Integration #
Pertukaran data via file (CSV, XML, JSON).
Contoh:
- Batch job harian
- Legacy ERP system
Risiko:
- Delay tinggi
- Error handling sulit
Database-Level Integration (Anti-Pattern) #
Mengakses database sistem lain secara langsung.
Kenapa harus dihindari:
- Break encapsulation
- Sangat fragile
- Hampir mustahil evolve schema
Pola Integrasi yang Umum Digunakan #
Synchronous Request-Response #
Client menunggu response langsung.
Contoh:
- Auth service
- Payment validation
Gunakan ketika:
- Butuh hasil langsung
- Latency rendah
Asynchronous Messaging #
Client kirim message, proses terjadi di background.
Gunakan ketika:
- Proses berat
- Tidak perlu response instan
Orchestration vs Choreography #
Orchestration:
- Ada central controller
- Flow jelas
Choreography:
- Event-based
- Setiap service reaktif
Best Practice System Integration #
Authentication & Authorization #
a. Jangan Percaya Request dari Sistem Lain #
Setiap integrasi HARUS diautentikasi.
Metode umum:
- OAuth 2.0 / OpenID Connect
- API Key + HMAC
- mTLS
- Signed JWT
b. Machine-to-Machine Auth #
Gunakan:
- Client Credentials Flow
- Short-lived token
Anti-pattern:
- Hardcoded token
- Token tanpa expiry
Data Exchange Contract #
a. Schema is a Contract #
Gunakan:
- OpenAPI / Swagger
- Protobuf schema
- JSON Schema
Rule penting:
- Backward compatibility
- Jangan hapus field sembarangan
b. Versioning Strategy #
Contoh:
/v1/orders- Header-based versioning
Request Integrity Check #
a. Kenapa Integrity Check Penting? #
Untuk mencegah:
- Data tampering
- Replay attack
- Man-in-the-middle
b. Teknik Umum #
1. HMAC Signature
- Payload + secret
- Server memverifikasi signature
2. Timestamp + Nonce
- Cegah replay attack
3. Signed JWT Payload
- Data tidak bisa dimodifikasi
Idempotency #
Request yang sama tidak boleh menghasilkan efek ganda.
Contoh kasus:
- Payment callback
- Order creation
Solusi:
- Idempotency-Key
- Unique request ID
Error Handling & Retry Strategy #
a. Jangan Retry Semua Error #
Retry hanya untuk:
- Network error
- Timeout
- 5xx
b. Gunakan Backoff #
- Exponential backoff
- Jitter
Observability dalam Integrasi #
a. Logging #
Log minimal:
- Request ID
- Correlation ID
- Source system
b. Metrics #
Pantau:
- Error rate
- Latency
- Throughput
c. Distributed Tracing #
Gunakan:
- OpenTelemetry
- Trace ID lintas service
Security Best Practice Tambahan #
- TLS wajib
- Rate limiting
- IP allowlist (jika perlu)
- Principle of least privilege
Contoh Kasus Nyata #
Bagian ini membahas contoh integrasi nyata yang sering ditemui di production, lengkap dengan pola, risiko, dan best practice-nya.
Webhook Integration (Push Model) #
Webhook adalah mekanisme push-based integration, di mana sistem A secara aktif mengirim event ke sistem B ketika suatu kejadian terjadi.
Contoh nyata:
- Payment gateway → Order service (payment success / failed)
- GitHub → CI/CD system (push event, PR event)
Flow umum:
- Sistem B mendaftarkan endpoint webhook
- Sistem A menyimpan endpoint tersebut
- Event terjadi di sistem A
- Sistem A melakukan HTTP POST ke endpoint webhook
Best practice webhook:
- Verifikasi signature (HMAC / public key)
- Gunakan timestamp + nonce (anti replay)
- Endpoint idempotent
- Proses async (jangan blocking webhook)
- Return HTTP 200 secepat mungkin
Risiko umum:
- Duplicate delivery
- Out-of-order event
- Endpoint down
Solusi:
- Idempotency key
- Event versioning
- DLQ untuk webhook processor
Service-to-Service Internal Integration #
Integrasi antar service internal (microservices atau modular service) tidak boleh dianggap trusted secara otomatis.
Contoh nyata:
- User service → Notification service
- Order service → Inventory service
Pola umum:
- REST / gRPC synchronous call
- Event-based async
Best practice internal S2S:
- Machine-to-machine auth (OAuth Client Credentials / mTLS)
- Short-lived token
- Timeout & circuit breaker
- Correlation ID
Anti-pattern:
- Akses database service lain
- Hardcoded internal secret
- No timeout
Pull-Based Integration #
Pada pull model, sistem B secara aktif mengambil data dari sistem A secara berkala.
Contoh nyata:
- Reporting service menarik data transaksi
- Sinkronisasi data legacy system
Flow umum:
- Scheduler di sistem B berjalan
- Sistem B request data ke sistem A
- Sistem A mengembalikan data incremental
Best practice pull:
- Gunakan cursor / watermark (last_updated_at)
- Pagination wajib
- Rate limit aware
- Retry dengan backoff
Kapan cocok:
- Data tidak real-time
- Sistem sumber tidak mendukung webhook
Push-Based Integration (Non-Webhook) #
Push-based tidak selalu webhook.
Contoh:
- Event streaming (Kafka / PubSub)
- Message queue (SQS / RabbitMQ)
Flow:
- Producer publish message
- Consumer subscribe dan memproses
Best practice:
- At-least-once delivery awareness
- Consumer idempotent
- Dead Letter Queue
- Schema registry
Hybrid Integration (Pull + Push) #
Banyak sistem production menggunakan kombinasi pull dan push.
Contoh nyata payment system:
- Push: payment gateway webhook
- Pull: reconciliation job harian
Tujuan:
- Reliability
- Data consistency
Internal Event vs External Event #
Internal event:
- Digunakan antar service internal
- Schema bisa evolve lebih cepat
External event:
- Kontrak harus stabil
- Versioning ketat
- Backward compatible
Contoh End-to-End: Order → Payment → Notification #
Flow ringkas:
- Order service create order
- Publish
OrderCreatedevent - Payment service proses pembayaran
- Payment gateway kirim webhook
- Order service verifikasi signature
- Publish
OrderPaidevent - Notification service kirim notifikasi
Best practice yang diterapkan:
- Event-driven
- Webhook signature verification
- Idempotency
- Correlation ID
- DLQ
Kesalahan Umum dalam System Integration #
- Menganggap internal system itu trusted
- Tidak punya versioning
- Tidak ada timeout
- Tidak ada retry strategy
- Tidak ada monitoring
Penutup #
System integration adalah fondasi dari scalable system architecture. Integrasi yang baik:
- Aman
- Terukur
- Tahan gagal
- Mudah dikembangkan
Bukan soal teknologi apa yang dipakai, tapi disiplin desain dan konsistensi best practice.
Jika integrasi Anda terasa rapuh, kemungkinan besar masalahnya bukan di code — tapi di desain integrasinya.