Tugas PPL Pertemuan 5

Nama     : Muhammad Ahyun Irsyada 

NRP       : 5025211251

Kelas      : PPL-A

High Level Design

Referensi : Referensi HLD

High Level Design (HLD)

High Level Design (HLD) adalah tahap dalam proses desain sistem atau perangkat lunak yang berfokus pada struktur dan arsitektur sistem secara keseluruhan. HLD memberikan gambaran umum tentang bagaimana sistem akan diorganisir dan berfungsi, dengan menekankan pada komponen utama dan interaksi di antara mereka. Ini adalah langkah awal sebelum memasuki desain detail yang lebih spesifik (Low Level Design atau LLD).

High Level Design Pada Sistem Design Twitter

Bagaimana anda mendesain Twitter ? Jangan langsung masuk ke detail teknis ketika Anda ditanya pertanyaan ini dalam wawancara Anda. Jangan berlari ke satu arah, itu hanya akan membuat kebingungan antara Anda dan pewawancara. Sebagian besar kandidat membuat kesalahan di sini dan segera mereka mulai mencantumkan beberapa alat atau kerangka kerja seperti MongoDB, Bootstrap, MapReduce, dll.

Ingatlah bahwa pewawancara Anda menginginkan ide-ide tingkat tinggi tentang bagaimana Anda akan memecahkan masalah. Tidak masalah alat apa yang akan Anda gunakan, tetapi bagaimana Anda mendefinisikan masalah, bagaimana Anda merancang solusi, dan bagaimana Anda menganalisis masalah langkah demi langkah. Anda dapat menempatkan diri Anda dalam situasi di mana Anda sedang mengerjakan proyek kehidupan nyata. Pertama, tentukan masalah dan klarifikasi pernyataan masalah. 

2. Persyaratan untuk Desain Sistem Twitter

2.1 Persyaratan Fungsional:

• Harus dapat memposting tweet baru (bisa berupa teks, gambar, video, dll).
• Harus bisa mengikuti pengguna lain.
• Harus memiliki fitur umpan berita yang terdiri dari tweet dari orang-orang yang diikuti pengguna.
• Harus dapat mencari tweet.

2.2 Persyaratan Non Fungsional:

• Ketersediaan tinggi dengan latensi minimal.
• Sistem ini harus terukur dan efisien.

2.3 Persyaratan yang Diperpanjang:

• Metrik dan analitik
• Fungsi retweet
• Tweet favorit

3. Estimasi Kapasitas untuk Desain Sistem Twitter

Untuk memperkirakan kapasitas sistem, kita perlu menganalisis rasio klik harian yang diharapkan.

3.1 Estimasi Lalu Lintas:

Mari kita asumsikan kita memiliki 1 miliar total pengguna dengan 200 juta pengguna aktif harian (DAU), dan rata-rata setiap pengguna tweets 5 kali sehari. Ini memberi kita 1 miliar tweet per hari.

200 juta * 5 tweet = 1 miliar/hari

Tweet juga dapat berisi media seperti gambar, atau video. Kita dapat mengasumsikan bahwa 10 persen tweet adalah file media yang dibagikan oleh pengguna, yang memberi kita tambahan 100 juta file yang perlu kita simpan.

10 persen * 1 miliar = 100 juta/hari

Untuk System Request per Second (RPS) kami adalah:

1 miliar permintaan per hari diterjemahkan menjadi 12 ribu permintaan per detik.

1 miliar / (24 jam * 3600 detik) = 12K permintaan/detik

3.2 Estimasi Penyimpanan:

Mari kita asumsikan setiap pesan rata-rata adalah 100 byte, kita akan membutuhkan sekitar 100 GB penyimpanan database setiap hari. 

1 miliar * 100 byte = 100 GB/hari

10 persen dari pesan harian kami (100 juta) adalah file media sesuai kebutuhan kami. Mari kita asumsikan setiap file rata-rata 50KB, kita akan membutuhkan penyimpanan 5 TB setiap hari.

100 juta * 50 KB = 5TB/hari

Selama 10 tahun membutuhkan penyimpanan 19 PB.

(5TB + 0,1 TB ) * 365 hari * 10 tahun = 19 PB

3.3 Estimasi Bandwidth

Karena sistem kami menangani 5,1 TB masuknya setiap hari, kami memerlukan bandwidth minimum sekitar 60 MB per detik.

5,1 TB / (24 jam * 3600 detik) = 60 MB/detik

4. Gunakan Desain Kasus untuk Desain Sistem Twitter

 

 Dalam Diagram di atas,

• Pengguna akan mengklik Halaman Twitter mereka akan mendapatkan halaman utama di dalam halaman utama, akan ada Halaman Beranda, Halaman Pencarian, Halaman Pemberitahuan.
• Di dalam Home Page akan ada halaman Tweet baru serta Post Image atau Video.
• Di Tweet baru di sana kita akan suka, tidak suka, komentar serta tombol ikuti / berhenti mengikuti.
• Pengguna Tamu hanya akan memiliki akses untuk melihat tweet apa pun.
• Penggunaan terdaftar dapat melihat dan memposting tweet. Dapat mengikuti dan berhenti mengikuti pengguna lain.
• Pengguna Terdaftar akan dapat membuat tweet baru.

5. Desain Tingkat Tinggi untuk Desain Sistem Twitter

 

5.1 Arsitektur:

Untuk twitter kami menggunakan arsitektur microservices karena akan membuatnya lebih mudah untuk skala horizontal dan memisahkan layanan kami. Setiap layanan akan memiliki kepemilikan model datanya sendiri. Kami akan membagi sistem kami menjadi beberapa layanan core.

5.2 Layanan Pengguna

Layanan ini menangani masalah terkait pengguna seperti otentikasi dan informasi pengguna. Halaman Login, halaman Pendaftaran, Halaman Profil dan halaman Beranda akan ditangani ke layanan Pengguna.

5.3 Layanan Umpan Berita:

Layanan ini akan menangani pembuatan dan penerbitan umpan berita pengguna. Kami akan membahas tentang umpan berita secara lebih rinci. Ketika datang ke umpan berita, tampaknya cukup mudah untuk diterapkan, tetapi ada banyak hal yang dapat membuat atau menghancurkan fitur ini.

5.4 Layanan Tweet:

Layanan tweet menangani kasus penggunaan terkait tweet seperti memposting tweet, favorit, dll.

5.5 Retweet :

Retweet adalah salah satu persyaratan tambahan kami. Untuk menerapkan fitur ini, kita cukup membuat tweet baru dengan id pengguna pengguna yang me-retweet tweet asli dan kemudian memodifikasi enum dan properti tweet baru untuk menautkannya dengan tweet asli.typecontent

5.6 Layanan Pencarian:

Layanan ini bertanggung jawab untuk menangani fungsionalitas terkait pencarian. Dalam layanan pencarian kami mendapatkan Top post, posting terbaru dll. Hal-hal ini kita dapatkan karena peringkat.

5.7 Layanan Media:

Layanan ini akan menangani unggahan media (gambar, video, file, dll.).

5.8 Layanan Analitik:

Layanan ini akan digunakan untuk kasus penggunaan metrik dan analitik.

5.9 Algoritma Peringkat:

Kami akan membutuhkan algoritma peringkat untuk memberi peringkat setiap tweet sesuai dengan relevansinya dengan setiap pengguna tertentu.

Contoh: Facebook digunakan untuk memanfaatkan algoritma EdgeRank. Di sini, peringkat setiap item umpan dijelaskan oleh:

Peringkat = Afinitas * Berat * Pembusukan

5.10 Layanan Pencarian

• Terkadang DBMS tradisional tidak cukup berkinerja, kita membutuhkan sesuatu yang memungkinkan kita untuk menyimpan, mencari, dan menganalisis volume data yang sangat besar dengan cepat dan mendekati real-time dan memberikan hasil dalam milidetik. Elasticsearch dapat membantu kami dengan kasus penggunaan ini.
• Elasticsearch adalah mesin pencarian dan analitik terdistribusi, gratis, dan terbuka untuk semua jenis data, termasuk tekstual, numerik, geospasial, terstruktur, dan tidak terstruktur. Itu dibangun di atas Apache Lucene.

5.11 Bagaimana kami mengidentifikasi topik yang sedang tren?

• Fungsi yang sedang tren akan didasarkan pada fungsionalitas pencarian.
• Kami dapat menyimpan kueri, tagar, dan topik yang paling sering dicari di detik-detik terakhir dan memperbaruinya setiap detik menggunakan semacam mekanisme pekerjaan batch. NM
• Algoritme peringkat kami juga dapat diterapkan pada topik yang sedang tren untuk memberi bobot lebih dan mempersonalisasikannya bagi pengguna.

5.12 Layanan Pemberitahuan:

• Pemberitahuan push adalah bagian integral dari platform media sosial apa pun.
• Kita dapat menggunakan antrian pesan atau broker pesan seperti Apache Kafka dengan layanan notifikasi untuk mengirimkan permintaan ke Firebase Cloud Messaging (FCM) atau Apple Push Notification Service (APNS) yang akan menangani pengiriman pemberitahuan push ke perangkat pengguna.