Pola Koreografi vs Orkestrasi
Bandingkan koreografi peristiwa (setiap layanan bereaksi secara mandiri) dengan orkestrasi (koordinator pusat mengarahkan layanan), lalu pilih pola yang tepat untuk arsitektur Anda.
Pola Koreografi vs Orkestrasi adalah pelajaran AWS Solutions Architect gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar AWS Solutions Architect, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus AWS Solutions Architect mencakup 4 pelajaran total.
Dua Pendekatan untuk Koordinasi Layanan Mikro
Ketika layanan mikro perlu bekerja sama untuk menyelesaikan suatu proses bisnis, terdapat dua pola koordinasi mendasar. Orchestration menggunakan koordinator pusat (seperti Step Functions) yang secara eksplisit memberi perintah kepada setiap layanan. Choreography tidak memiliki koordinator pusat — layanan mendengarkan peristiwa dan bereaksi secara independen. Memahami pola mana yang harus digunakan, dan kapan keduanya perlu digabungkan, merupakan keterampilan arsitektur penting yang diujikan dalam ujian SAA-C03.
Penjelasan Pola Orchestration
Dalam orchestration, layanan pusat (orchestrator) mengendalikan urutan operasi. Layanan tersebut memanggil Layanan A, menunggu respons, kemudian memanggil Layanan B, dan seterusnya. Orchestrator memiliki visibilitas penuh terhadap status proses, menangani galat dan percobaan ulang, serta dapat mengambil keputusan berdasarkan hasil antara. Di AWS, Step Functions adalah orchestrator kanonis — layanan ini mendefinisikan seluruh alur kerja sebagai mesin status dan menjalankan setiap langkah.
# Orchestration: Step Functions state machine drives order processing
# StepFunctions -> ValidateOrder Lambda -> ChargePayment Lambda -> NotifyShipping Lambda
# Each arrow is an explicit command from the orchestrator
# If ChargePayment fails, Step Functions catches the error and routes to NotifyFailure
# The orchestrator (Step Functions) knows the full state of the order at every momentPenjelasan Pola Choreography
Dalam choreography, layanan berkomunikasi melalui peristiwa tanpa koordinator pusat. Layanan A menyelesaikan tugasnya dan menerbitkan peristiwa (misalnya, OrderValidated) ke bus peristiwa atau topik. Layanan B mendengarkan peristiwa OrderValidated dan memproses pembayaran, lalu menerbitkan PaymentCharged. Layanan C mendengarkan PaymentCharged dan mengirimkan pesanan. Setiap layanan bersifat otonom dan tidak saling terikat — layanan tersebut hanya mengetahui peristiwa yang dikonsumsi dan dihasilkannya, bukan layanan lainnya.
# Choreography: EventBridge bus connects services without central coordinator
# OrderService -> publishes 'OrderPlaced' to EventBridge
# PaymentService -> listens for 'OrderPlaced', charges card, publishes 'PaymentCharged'
# ShippingService -> listens for 'PaymentCharged', creates shipment, publishes 'OrderShipped'
# NotificationService -> listens for 'OrderShipped', sends email
# No service calls another service directly — all communication is via eventsLayanan AWS untuk Setiap Pola
Di AWS, Step Functions adalah alat utama untuk orchestration. Untuk choreography, alat utamanya adalah Amazon EventBridge (untuk merutekan peristiwa antar layanan dengan pemfilteran berbasis konten), Amazon SNS (untuk fan-out sederhana), dan Amazon SQS (untuk pengiriman pesan titik ke titik antar layanan). Anda dapat menggabungkan pola-pola tersebut: gunakan EventBridge untuk choreography lintas domain di antara konteks terbatas, dan Step Functions untuk mengatur langkah-langkah dalam satu domain.
Pertukaran: Observabilitas
Orchestration menyediakan visibilitas terpusat — riwayat eksekusi Step Functions menunjukkan dengan tepat posisi alur kerja, durasi setiap langkah, dan hal yang gagal. Proses penelusuran masalah menjadi mudah. Choreography mendistribusikan visibilitas ke berbagai layanan dan bus peristiwa — menelusuri satu transaksi bisnis memerlukan pengaitan log dan peristiwa di banyak layanan. Inilah alasan sistem choreography sangat bergantung pada ID korelasi dan pelacakan terdistribusi (AWS X-Ray) untuk mendapatkan visibilitas menyeluruh.
# Correlation ID pattern for choreography observability
# Every event includes a correlationId that flows through the entire chain
{
'source': 'com.myapp.orders',
'detail-type': 'OrderPlaced',
'detail': {
'orderId': 'ORD-123',
'correlationId': 'CORR-abc-456', # propagated to every downstream event
'customerId': 'CUST-789',
'total': 99.99
}
}Pertukaran: Keterikatan
Choreography menawarkan keterikatan yang lebih longgar — menambahkan layanan baru yang mendengarkan peristiwa yang sudah ada tidak memerlukan perubahan pada layanan yang sudah ada. Misalnya, menambahkan layanan analitik yang mendengarkan peristiwa OrderPlaced tidak berdampak pada layanan pesanan atau pembayaran. Orchestration memperkenalkan keterikatan yang lebih erat antara orchestrator dan semua layanan yang dipanggilnya — penambahan langkah baru memerlukan perubahan pada definisi mesin status, meskipun setiap layanan tetap terisolasi.
Pertukaran: Penanganan Galat
Orchestration membuat penanganan galat menjadi eksplisit — blok Catch Step Functions mendefinisikan status pengganti untuk setiap jenis galat, dan seluruh riwayat alur kerja menampilkan konteks kegagalan. Dalam choreography, penanganan galat didistribusikan — setiap layanan harus menangani kegagalannya sendiri dan dapat menerbitkan peristiwa kegagalan yang dapat ditanggapi oleh layanan lain. Penerapan saga (transaksi kompensasi untuk membatalkan pekerjaan ketika suatu langkah gagal) jauh lebih kompleks dalam choreography dibandingkan dalam orchestration.
# Saga pattern in choreography: compensating events
# Happy path:
# OrderPlaced -> PaymentCharged -> InventoryReserved -> OrderShipped
#
# Failure path (InventoryReservation fails):
# InventoryReservationFailed event published
# PaymentService listens -> issues refund -> publishes PaymentRefunded
# OrderService listens -> cancels order -> publishes OrderCancelled
#
# In orchestration (Step Functions), the compensating logic is in explicit Catch statesKapan Memilih Orchestration
Utamakan orchestration ketika: proses bisnis memiliki urutan linear atau bercabang yang jelas dengan hasil berhasil/gagal yang eksplisit; Anda memerlukan visibilitas terpusat terhadap status proses untuk operasional atau kepatuhan; penanganan galat melibatkan logika kompensasi yang kompleks; atau alur kerja berlangsung lama dan harus bertahan setelah layanan dimulai ulang. Contohnya adalah pemenuhan pesanan, pendaftaran pasien, dan pemrosesan klaim asuransi — semua alur kerja dengan persyaratan awal, akhir, dan audit yang jelas.
Kapan Memilih Choreography
Utamakan choreography ketika: layanan dimiliki oleh tim yang berbeda dan tidak seharusnya dikoordinasikan secara erat; sistem harus terbuka untuk diperluas oleh layanan baru tanpa mengubah layanan yang sudah ada; peristiwa merepresentasikan fakta, bukan perintah (misalnya, 'OrderShipped', bukan 'ShipOrder'); atau Anda menginginkan skalabilitas maksimum karena tidak ada hambatan pusat. Contohnya adalah penyerapan analitik, penyebaran notifikasi, dan pencatatan audit — semua kasus ketika beberapa konsumen independen bereaksi terhadap peristiwa yang sama.
Arsitektur Hibrida
Sebagian besar arsitektur AWS di dunia nyata menggunakan kedua pola pada tingkat perincian yang berbeda. Contoh hibrida yang umum: gunakan choreography EventBridge untuk memisahkan konteks terbatas (misalnya, domain Order menghasilkan peristiwa; domain Inventory, Payment, dan Shipping masing-masing merespons secara independen), sementara di dalam domain Payment, gunakan orchestration Step Functions untuk mengoordinasikan langkah-langkah alur kerja pembayaran internal (menagih, memeriksa penipuan, mengotorisasi, menyelesaikan). Dengan demikian, keterkaitan antar-domain menjadi longgar, sementara proses internal tetap jelas.
# Hybrid: EventBridge for inter-domain + Step Functions for intra-domain
#
# EventBridge bus (choreography):
# Order domain publishes 'OrderPlaced'
# Payment domain receives it, starts Step Functions execution
#
# Step Functions (orchestration inside Payment domain):
# ValidateCard -> FraudCheck -> AuthorisePayment -> SettlePayment
# On success: PaymentDomain publishes 'PaymentCharged' to EventBridge bus
# On failure: Step Functions Catch -> publishes 'PaymentFailed' eventSinyal Ujian SAA-C03
Dalam ujian, perhatikan sinyal-sinyal berikut. Kata kunci Choreography: 'loose coupling', 'layanan merespons peristiwa', 'tim memiliki layanan independen', 'fan-out ke banyak konsumen', 'menambahkan layanan baru tanpa mengubah layanan yang sudah ada'. Kata kunci Orchestration: 'mengoordinasikan langkah secara berurutan', 'melacak status alur kerja', 'menangani kegagalan sebagian dengan kompensasi', 'langkah persetujuan manusia', 'proses yang berjalan lama dengan penanganan kesalahan'. Pertanyaan yang menjelaskan koordinator pusat yang mengarahkan layanan lain selalu merupakan orchestration.
Pemeriksaan Singkat
Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.
Ringkasan Pelajaran
Dalam pelajaran ini, Anda mempelajari bahwa: orchestration menggunakan koordinator pusat (Step Functions) untuk mengendalikan alur kerja secara eksplisit dan terlihat, choreography menggunakan peristiwa (EventBridge) untuk keterkaitan yang longgar dan kemampuan perluasan, serta sebagian besar arsitektur produksi menggabungkan kedua pola tersebut pada tingkat perincian yang berbeda. Selanjutnya, kita akan membahas format ujian SAA-C03 dan strategi bobot domain.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Pola Koreografi vs Orkestrasi” gratis?
Ya — teks lengkap “Pola Koreografi vs Orkestrasi” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus AWS Solutions Architect, upgrade ke CoddyKit PRO. Kursus AWS Solutions Architect mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Pola Koreografi vs Orkestrasi”?
Bandingkan koreografi peristiwa (setiap layanan bereaksi secara mandiri) dengan orkestrasi (koordinator pusat mengarahkan layanan), lalu pilih pola yang tepat untuk arsitektur Anda. Kamu berlatih AWS Solutions Architect dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai AWS Solutions Architect?
Tidak diperlukan pengalaman sebelumnya. AWS Solutions Architect di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Pola Koreografi vs Orkestrasi” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran AWS Solutions Architect ini?
Ya. Setiap pelajaran AWS Solutions Architect menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- EventBridge: Bus Peristiwa dan Aturan
- Step Functions: Mengatur Alur Kerja Tanpa Server
- Kinesis Data Streams untuk Pemrosesan Peristiwa Waktu Nyata
- Pola Koreografi vs Orkestrasi