10:44 Sama seperti konsep consumer group pada Kafka, intinya consuming message secara parallel dari banyak paritisi topic, tidak harus banyak service kalau di kafka
request cara kerja message broker, bagaimana dia mengirim data ke service yang dituju. bagaimana suatu service menghandle data yang dikirim message broker
message broker tidak bisa untuk pattern dimana action di service yang menggenerate event ke message broker dan action di service yang meng consume harus 'transactional' ya
Membahas satu service bermasalah mempengaruhi service lain yg ketergantungan jd teringat circuit breaker mas.. mungkin kapan2 bisa dibahas juga. Hehehe
Pak, mau tanya, diakhir video bapak bilang, semua aplikasi jd bergantung pd message broker, sehingga kita wajib memilih message broker yg handal.. yg ingin sy tnykan adalah apa solusi jika message broker ini down ( baik secara server/service) , best practice handling nya gmn?
kalau saya tarik kesimpulan berarti message broker hanya berlaku untuk aplikasi yang sifatnya tidak saling ketergantungan, tidak berlaku untuk aplikasi yang sifatnya end to end transaction ya
kenapa kakak bilang jika terdapat salah satu service yang bergantung dengan order service bermasalah, maka service order tersebut tidak akan bekerja juga? jika dibuat microservices seperti itu, apakah semua service harus bekerja 100% untuk dapat dikatakan sistemnya "bekerja"?. Jika iya, apakah tidak boleh ada satupun service yang bergantung itu bermasalah meskipun sebenarnya service tersebut termasuk opsional?
Keren! tq banget pak, jadi paham soal message broker. Mau tanya juga, apa message broker ini sama seperti queuing service ? atau sebenarnya message broker ini memakai konsep queuing service ?
Kalo aplikasinya mati dalam waktu lama lalu dinyalakan kembali gimana mas, aplikasinya akan terima banyak data ya? Anggap saja OrderService memiliki transaksi 3data/sec, lalu NotificationService mati selama 1 bulan, berarti data yang akan diterima NotificationService ketika dinyalakan kembali sekitar 3*60*60*24*30=7,776,000 data order dalam satu waktu ya? Nanti aplikasinya gak hang kah?
iya, notificationservice akan menerima semua data yang belum pernah dia terima. tapi tidak sekaligus semua diterima, diterima satu per satu sesuai dengan kemampuan konsumsi Notification service nya
@@ProgrammerZamanNow pak mau tanya juga nih. kalo misalkan diproses satu persatu gitu sesuai antrian atau gimana pak? kalo misalkan sesuai antrian berarti memakan waktu yg lama kan, nah gimana cara untuk ngakalin supaya antrian bisa lebih cepat? apakah kita perlu threading untuk mengatasi antrian tersebut?
@@RaldesKrisnuPratama iya antrian, tinggal dibesarkan aja jumlah consumer nya, kalo butuh lebih cepat. Ibarat antri di bank, kalo mau makin cepat, banyakin teller nya
kalo pas notif service nyala dan broker kirim message yg pending, ternyata notif service masih error, apa message yg dikirim si broker ini dianggap sudah terkirim? apa ada mekanisme sendiri si broker utk nandai si service tujuan sukses proses message nya? ide materi simple aja mas : best practice untuk unit testing 😁
Saya masih tidak familiar dengan paradigma async dalam passing data. Bagaimana saat saya mengirim data tapi saya juga perlu menunggu hasilnya? apakah saya tetap harus post langsung ke servicenya atau apakah message broker bisa juga menangani masalah ini? Semoga banyak pembahasan lagi soal #SoftwareArchitecture di video selanjutanya :D
yup, saat kita pindah menggunakan message broker, masa mau gak mau, cara kerja aplikasi nya emang harus diubah, gak bisa sync lagi. salah satu caranya buat komunikasi 2 arah, jadi order service mengirim message ke message broker untuk dikirim ke notification service, selanjutnya setelah notification service sukses mengirim email, notification service mengirim status ke message broker untuk dikirim ke order service memang lumayan harus banyak berubah :D
I see, apakah saat menerima data dari broker, ini bisa di forward ke http response? semisal kita ingin mengembalikan value ke user dari hasil data yg di submit
Kayaknya, solusi ini hadir untuk web yang request per detiknya memang banyak. Supaya sistem tetep responsive menangani request gede. Soal response ya betul jadi async (pake callbacks) karena nunggu message broker ngabarin lagi. *cmiiw
Om eko, request ... video selanjutnya step by step migrasi monolith to microservice 😁
noted
+1. Mungkin konsep microservicesnya juga 😂
Ditunggu nih topiknya mas Eko
CI/CD juga Jenkins
thanks a lot utk content2nya.. priceless banget nih.. terutama utk g yang butuh extra effort ketika baca docs / tutorial bahasa inggris.
Bener penjelasan om eko enak banget dipahami
Luar biasa, mas eko ini masih muda, cerdas..pintar.. pengen punya anak kaya mas eko.. 😁
bang, request ilmu database nya dong, jarang2 ada yg bahas database programming, kaya sp, cursor, optimasi query
10:44 Sama seperti konsep consumer group pada Kafka, intinya consuming message secara parallel dari banyak paritisi topic, tidak harus banyak service kalau di kafka
mantapppl bang ekoooo mondar mandir mulu ana ke chanel mas eko
very nice and clear information, mas !.
ilmu mahal ini
makasih mas terpecahkan sudah problem saya selama ini hehe
salam di tahun 2021, mas habis saya lihat video ini, perbedaan cron job queue, sama message broker apa ya ?
Bener2 harus melek teknologi
Terimakasih penjelasannya sangat clear dan simple dimengeri Mas Eko
terima kasih atas info materi nya, sangat bermanfaat
arah dari pembicaraan message broker jadi nge triggered konsep microservices ya pak eko hahaha... mantul pak eko
Request bahas Event Sourcing Pak Eko. Daripada ke Message Broker, masukin ke Event Source. Terima kasih
Makasih bg, sering sering buat konten tentang software architrcture ya bg
makasih mas ilmu bermanfaat
saya saya pantengin 2008
tapi saya nonton ulang 2020
request cara kerja message broker, bagaimana dia mengirim data ke service yang dituju. bagaimana suatu service menghandle data yang dikirim message broker
Noted
request om.. bahas tentang service orchestration vs service choreography
Terima kasih videonya mas, sangat informatif.
mantap mas ditunggu update nya, request dong mas penjelasan tentang Service Mesh.. heheh
makasi bg buat materi nya, sangat membantu dalam tugas saya 🤩
makasih om, bermanfaat sekali
message broker tidak bisa untuk pattern dimana action di service yang menggenerate event ke message broker dan action di service yang meng consume harus 'transactional' ya
Membahas satu service bermasalah mempengaruhi service lain yg ketergantungan jd teringat circuit breaker mas.. mungkin kapan2 bisa dibahas juga. Hehehe
selain untuk notification, penerapan message broker di dunia kerja apalagi ya biasanya?
bang request pembahasan dari basic sampai advance (kalo bisa) terkait best practice teknis stress test
Pak, mau tanya, diakhir video bapak bilang, semua aplikasi jd bergantung pd message broker, sehingga kita wajib memilih message broker yg handal.. yg ingin sy tnykan adalah apa solusi jika message broker ini down ( baik secara server/service) , best practice handling nya gmn?
om. rekomen best practice nya dong
Bang eko, request bahas web socket dong Terima kasih...
Mau Tanya I'm..klo misal kebutuhan transfer data antar table database bisa ga pke ini?
kalau saya tarik kesimpulan berarti message broker hanya berlaku untuk aplikasi yang sifatnya tidak saling ketergantungan, tidak berlaku untuk aplikasi yang sifatnya end to end transaction ya
Ntah kenapa dari penjelasan ini baru ngeh dulu waktu awal2 tokped berdiri waktu search barang aja lamanya setengah mati 🤣🤣
kenapa kakak bilang jika terdapat salah satu service yang bergantung dengan order service bermasalah, maka service order tersebut tidak akan bekerja juga?
jika dibuat microservices seperti itu, apakah semua service harus bekerja 100% untuk dapat dikatakan sistemnya "bekerja"?. Jika iya, apakah tidak boleh ada satupun service yang bergantung itu bermasalah meskipun sebenarnya service tersebut termasuk opsional?
Keren! tq banget pak, jadi paham soal message broker.
Mau tanya juga, apa message broker ini sama seperti queuing service ? atau sebenarnya message broker ini memakai konsep queuing service ?
Queue biasanya jadi salah satu fasilitas yg ada di message broker
Owwhhh.. jadi queue termasuk salah satu fitur dari message broker.. siapp tq pak infonya 👍
Maaf mas mau tanya, kalo untuk xmpp dan web socket apa bedanya? Apakah keduanya termasuk teknologi yg digunakan oleh message broker?
Notifikasi service yg dimksd apa pak? Sory baru belajar 🙏
mas eko kira" ada contoh studi kasus nya gitu nggk? berupa codingan
Om request bahas service mesh
bagus, sangat membantu pak.
Kalo aplikasinya mati dalam waktu lama lalu dinyalakan kembali gimana mas, aplikasinya akan terima banyak data ya? Anggap saja OrderService memiliki transaksi 3data/sec, lalu NotificationService mati selama 1 bulan, berarti data yang akan diterima NotificationService ketika dinyalakan kembali sekitar 3*60*60*24*30=7,776,000 data order dalam satu waktu ya?
Nanti aplikasinya gak hang kah?
iya, notificationservice akan menerima semua data yang belum pernah dia terima. tapi tidak sekaligus semua diterima, diterima satu per satu sesuai dengan kemampuan konsumsi Notification service nya
@@ProgrammerZamanNow pak mau tanya juga nih. kalo misalkan diproses satu persatu gitu sesuai antrian atau gimana pak? kalo misalkan sesuai antrian berarti memakan waktu yg lama kan, nah gimana cara untuk ngakalin supaya antrian bisa lebih cepat? apakah kita perlu threading untuk mengatasi antrian tersebut?
@@RaldesKrisnuPratama iya antrian, tinggal dibesarkan aja jumlah consumer nya, kalo butuh lebih cepat. Ibarat antri di bank, kalo mau makin cepat, banyakin teller nya
bagus banget..tks
so nyawa layanan nya tergantung sama message broker dong ya
Mas eko, kalau message broker nya yg bermasalah itu bagaimana ya kasusnya ?
sepertinya ini yg tidak bisa dijawab.. :)
mas eko saya ingin bertanya mengenai workflow engine seperti cadence/conductor netflix apakah itu cukup untuk membuat saga pattern
Adakah referensi dalam bentuk buku fisik maupun e-book (bahasa indo maupun english) ??
Masuk Pak eko... Keren mas videonya.
saran dong, ngambil lokasi di beberapa tempat yang berbeda :p
hehehe, sip, next video nyari tempat lain
bagus gan terusin hehehe klu bs yg lbh kompleks mas masalahnya biar seru
makasih banyak mas eko
kalo pas notif service nyala dan broker kirim message yg pending, ternyata notif service masih error, apa message yg dikirim si broker ini dianggap sudah terkirim? apa ada mekanisme sendiri si broker utk nandai si service tujuan sukses proses message nya?
ide materi simple aja mas : best practice untuk unit testing 😁
ini tergantung dari message broker yang kita pilih, contohnya di kafka, jika consumer tidak melakukan commit (sukses), maka message bisa dikirim ulang
Saya masih tidak familiar dengan paradigma async dalam passing data. Bagaimana saat saya mengirim data tapi saya juga perlu menunggu hasilnya? apakah saya tetap harus post langsung ke servicenya atau apakah message broker bisa juga menangani masalah ini?
Semoga banyak pembahasan lagi soal #SoftwareArchitecture di video selanjutanya :D
yup, saat kita pindah menggunakan message broker, masa mau gak mau, cara kerja aplikasi nya emang harus diubah, gak bisa sync lagi.
salah satu caranya buat komunikasi 2 arah, jadi order service mengirim message ke message broker untuk dikirim ke notification service, selanjutnya setelah notification service sukses mengirim email, notification service mengirim status ke message broker untuk dikirim ke order service
memang lumayan harus banyak berubah :D
I see, apakah saat menerima data dari broker, ini bisa di forward ke http response?
semisal kita ingin mengembalikan value ke user dari hasil data yg di submit
Kayaknya, solusi ini hadir untuk web yang request per detiknya memang banyak. Supaya sistem tetep responsive menangani request gede. Soal response ya betul jadi async (pake callbacks) karena nunggu message broker ngabarin lagi. *cmiiw
kalo pake table yang nampung queue message? bisa kah? tanpa harus pakai mssg broker, jadi tinggal di queuing di table itu aja
gak cocok struktur nya kalo disimpan di table
@@ProgrammerZamanNow rabbitmq ga pake db emangnya bang?
Bermanfaat
Sekelas ecomerce besar apakah memakai msgbroker juga.?..
semua ecommerce besar pasti pake
Gimana kalo yang error/mati adalah message broker nya? Apa semua message yang belum terkirim hilang?
sudah saya bahas di bagian terakhir di video nya
message yang belum terkirim tapi sudah diterima message broker, dia tetep ada, tidak akan hilang
kalo ga salah nilai retensinya ya
mirip email ya bang
kalau message broker bisa error ngga?
Klw di AWS ada SQS
kalo sekarang menggunakan redis sbg jembatan dan antrian.
lebih baik menggunakan message broker ini atau redis pak?
kalo sederhana, bisa pake redis, tapi kalo udah kompleks, lebih baik pake message broker
Lagi heboh debat monolith & microservices, tapi jujur masih ngga ngerti bang, wkwkwk. bahas donk
Bedanya sama queue apa mas?
lah ini Queue om..
nah iya nih.. bedanya apa ya bang?
Queue dibahas di video, bagian mendistribusikan pekerjaan
Queue ke memory juga queue namanya. Message broker running diatas konsep queue.
imagine..... dislike this video