sudah menyerap segudang ilmu hari ini. ditunggu video mock interview system design yg baru mas. terima kasih banyak dan sukses terus mas gogo, ilmunya sangat bermanfaat
terima kasih banyak, mas. ini system design paling mantab dan mudah dimengerti. semoga menjadi ilmu yang bermanfaat. dan semoga saya bisa juga seperti mas yang bisa ngeshare ilmu-ilmu mengenai software development
design implement di perhitungannya manteps mas, gak sampai kepikiran kesana. wkwkwk,... baru pengalaman impact sampai sejauh mana klau bikin di back end
nice mass,, jadi kelihatannya untuk hal2 yang butuh banyak processing berat : 1. async 2. prepocessing 3. not a normalized database and avoid joining 4. mungkin menambahkan restriction di functional requirement ? seperti yang muncul di home cuma sampai tweet x bulan terakhir ? -> dari sini kita bisa main2 lebih ke design-nya
@@saipulmuizmuizcyan jujur daku tidak tau ini pake apa exactly. Daku ke toko Samsung, nyari tablet yang bisa masukin SIM juga (jadi bisa konek internet walau ga ada wifi). Tapi exactly Samsung apaan ga tau wkwkwk
pertanyaan yang bagus sekali! jadi sebenernya bisa pakai page sebagai integer. Tapi ada bbrp problem yang terjadi: 1. kalau kita ambil pagenya dari yang terbaru (misal 0-10), lalu dari backend ada 5 data baru, ketika kita fetch page 2, yang terjadi adalah kita bakal ambil data 5-15 (harusnya kita ambil data 10-20) 2. page 1, 2, 3 perlu digabungin dengan page size. Misalnya kita fetch page 2 dengan page size 10 (bakal ambil 10-20) bakal berbeda dengan page 2 dengan page size 5 (bakal ambil 5-10). Bayangkan apa yang terjadi ketika subsequent fetch kita kita ganti page sizenya (dengan page yang sama) Sehingga cara solve ini adalah dengan mengganti cara pagination dari "eh habis INDEX x ada apa lagi?" menjadi "eh habis ITEM x ada apa lagi?". Dan untuk bisa mencari ITEM x, preferably secepat mungkin, caranya pakai UUID, which refers to the encoded of tweet_id + user_id (ga bisa pakai tweet_id aja soalnya ITEMnya itu unique di home pagenya si user_id). Jauh lebih susah implementasinya, tapi behaviornya bakal lebih konsisten Bisa dicek kalau Facebook Graph API juga pagingnya pakai ID, bukan pake integer developers.facebook.com/docs/graph-api/results
mungkin instead of cron job bisa diliat sebagai map reduce pipeline juga tapi ga akan masalah dengan jumlah users dan tweets asalkan users dan tweetnya di index dan dipartisi based on tanggal, jadi querynya cepat
sudah menyerap segudang ilmu hari ini.
ditunggu video mock interview system design yg baru mas.
terima kasih banyak dan sukses terus mas gogo, ilmunya sangat bermanfaat
ini channel gila sih, isinya daging semua 🤩
siap digoreng 🍖
terima kasih banyak, mas. ini system design paling mantab dan mudah dimengerti.
semoga menjadi ilmu yang bermanfaat. dan semoga saya bisa juga seperti mas yang bisa ngeshare ilmu-ilmu mengenai software development
asik, makasih komennya
Bisa komen juga kalau ada hal2 yang pingin saya bahas lebih lanjut (boleh ga related ke interview juga)
Firstt mantaps Mas berkah dan semanga terus mas hehehehe
amiiin, makasi doanya dan supportnya
good sharing, mas.. semoga bisa bahas berbagai macam case jadi bisa tau karakteristik dari masing-masing.. mantap!
siap, nanti kita desain sistem yang lain
design implement di perhitungannya manteps mas, gak sampai kepikiran kesana. wkwkwk,... baru pengalaman impact sampai sejauh mana klau bikin di back end
asik. Emang ngitung tipis2 penting sih
nice mass,, jadi kelihatannya untuk hal2 yang butuh banyak processing berat :
1. async
2. prepocessing
3. not a normalized database and avoid joining
4. mungkin menambahkan restriction di functional requirement ? seperti yang muncul di home cuma sampai tweet x bulan terakhir ? -> dari sini kita bisa main2 lebih ke design-nya
Mantap mas
mantap mas berkah selalu ilmunya.. kalo bisa nambah lagi dong system design case yang lain hehe.. misalkan system design SAAS mas hee
Siaap nanti ditambah. Tapi mungkin bikin konten2 bodoh dulu baru yang serius lagi wkwkwkwkw
@@lwastuargo ok siap mas, thx response ny.. btw spill dong tablet yang dipake hehe
@@saipulmuizmuizcyan jujur daku tidak tau ini pake apa exactly. Daku ke toko Samsung, nyari tablet yang bisa masukin SIM juga (jadi bisa konek internet walau ga ada wifi). Tapi exactly Samsung apaan ga tau wkwkwk
@@lwastuargo Oh iya siap haha..
boleh diperjelas mas paging UUID itu gmn? kenapa gk pake integer aja misal page 1, nextnya page 2?
pertanyaan yang bagus sekali!
jadi sebenernya bisa pakai page sebagai integer. Tapi ada bbrp problem yang terjadi:
1. kalau kita ambil pagenya dari yang terbaru (misal 0-10), lalu dari backend ada 5 data baru, ketika kita fetch page 2, yang terjadi adalah kita bakal ambil data 5-15 (harusnya kita ambil data 10-20)
2. page 1, 2, 3 perlu digabungin dengan page size. Misalnya kita fetch page 2 dengan page size 10 (bakal ambil 10-20) bakal berbeda dengan page 2 dengan page size 5 (bakal ambil 5-10). Bayangkan apa yang terjadi ketika subsequent fetch kita kita ganti page sizenya (dengan page yang sama)
Sehingga cara solve ini adalah dengan mengganti cara pagination dari "eh habis INDEX x ada apa lagi?" menjadi "eh habis ITEM x ada apa lagi?". Dan untuk bisa mencari ITEM x, preferably secepat mungkin, caranya pakai UUID, which refers to the encoded of tweet_id + user_id (ga bisa pakai tweet_id aja soalnya ITEMnya itu unique di home pagenya si user_id).
Jauh lebih susah implementasinya, tapi behaviornya bakal lebih konsisten
Bisa dicek kalau Facebook Graph API juga pagingnya pakai ID, bukan pake integer developers.facebook.com/docs/graph-api/results
kak gogo mau nanya kenapa ecommerce kok lebih milih strong consistency padahal tidak ada item yang bisa di edit oleh 2 user secara bersamaan
Ada, stock dari suatu product misalnya. Banyak pembelianbisa mengurangi stok dari produk yan sama.
Penjelasan yang sangat bagus sekali mas.👍
tapi apakah cronjob opsi yang bagus jika users dan tweets sudah cukup banyak?
mungkin instead of cron job bisa diliat sebagai map reduce pipeline juga
tapi ga akan masalah dengan jumlah users dan tweets asalkan users dan tweetnya di index dan dipartisi based on tanggal, jadi querynya cepat