Tugas 4 PPL

Nama : M. Armand Giovani

NRP : 5025211054

Kelas : PPL A


High Level Design 

Deskripsi High Level Design

        High-level design (HLD) merupakan tahap awal dalam proses desain sistem. Tahap ini terutama berfokus pada identifikasi dan pemodelan komponen utama sistem, serta menggambarkan hubungan dan interaksinya. Tujuan utamanya adalah untuk menguraikan gambaran umum yang komprehensif tentang bagaimana sistem akan berfungsi, dengan sengaja menghindari detail rinci mengenai implementasi teknis setiap komponen.

        Aspek-aspek yang dipertimbangkan dalam desain tingkat tinggi meliputi identifikasi komponen penting, penentuan interaksi komponen, skalabilitas, keandalan, keamanan, dan kinerja sistem secara keseluruhan. Desain tingkat tinggi menetapkan kerangka kerja yang berfungsi sebagai landasan dasar untuk tahap selanjutnya dalam proses desain - yaitu desain terperinci. Selama tahap selanjutnya ini, spesifikasi teknis yang lebih rumit dari setiap komponen dan interaksinya lebih lanjut diuraikan. Dengan demikian, desain tingkat tinggi memberikan fondasi yang kuat untuk pengembangan sistem yang komprehensif.

Deskripsi High Level Design Twitter

  Referensi yang digunakan yaitu :
     https://www.geeksforgeeks.org/design-twitter-a-system-design-interview-question/ 


Desain tingkat tinggi dari sistem Twitter melibatkan penjelasan komprehensif tentang arsitektur menyeluruh platform. Hal ini termasuk mengidentifikasi dan memodelkan komponen utama sistem beserta interaksinya. Fokus utamanya adalah pada aspek-aspek yang luas seperti komponen utama, interaksi antar-komponen, skalabilitas, keandalan, keamanan, dan kinerja. Desain tingkat tinggi berfungsi sebagai fondasi untuk tahap selanjutnya dalam proses desain sistem-Desain Detail-di mana detail teknis setiap komponen dan interaksinya diuraikan lebih lanjut. Hal ini memungkinkan tim untuk berkonsentrasi pada aspek teknis dan implementasi berdasarkan arsitektur yang ditetapkan selama fase Desain Tingkat Tinggi.

        Dalam membuat desain tingkat tinggi untuk sistem Twitter, penekanan diberikan pada pemahaman struktur umumnya. Hal ini mencakup penentuan pendekatan arsitektur secara keseluruhan, termasuk bagaimana pengguna berinteraksi dengan feed; sistem manajemen data yang digunakan untuk menyimpan dan mengakses tweet; serta pemrosesan dan tampilan data pengguna secara real-time. Pertimbangan lebih lanjut mencakup strategi penskalaan untuk mengakomodasi volume pengguna yang signifikan secara andal dan efisien, kecepatan akses data yang cepat, dan menciptakan antarmuka pengguna yang intuitif yang meningkatkan kegunaan tanpa mengorbankan kinerja atau batasan keamanan dalam jadwal yang ketat yang sering dikaitkan dengan sesi wawancara teknis.

Persyaratan Perancangan Sistem Twitter

1. Persyaratan Fungsional:

  • Harus bisa 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 bisa mencari tweet.

2. Persyaratan Non Fungsional:

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

3. Persyaratan yang Diperpanjang:

  • Metrik dan analitik
  • Fungsi retweet
  • Tweet favorit
Estimasi Kapasitas Perancangan Sistem Twitter

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

1 Estimasi Lalu Lintas:

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

200 juta * 5 tweet = 1 miliar/hari

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

10 persen * 1 miliar = 100 juta/hari

Untuk Permintaan Sistem per Detik (RPS) kami adalah:

1 miliar permintaan per hari berarti 12 ribu permintaan per detik.

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

2 Estimasi Penyimpanan:

Mari kita asumsikan setiap pesan rata-rata berukuran 100 byte, kita memerlukan sekitar 100 GB penyimpanan database setiap hari.

100 miliar * 100 byte = 100 GB/hari

10 persen dari pesan harian kami (100 juta) adalah file media sesuai kebutuhan kami. Anggaplah setiap file rata-rata berukuran 50KB, kita memerlukan penyimpanan 5 TB setiap hari.

100 juta * 50 KB = 5TB/hari

Selama 10 tahun membutuhkan penyimpanan 19 PB.

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

3 Estimasi Bandwidth

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

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

Use Case Diagram Desain Sistem Twitter 

Pada 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 Halaman Beranda akan ada halaman Tweet baru serta Posting Gambar atau Video.

Di Tweet baru kita akan memiliki tombol 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.


HLD Desain Sistem Twitter



High Level Design untuk desain sistem Twitter:

1. Arsitektur:

Twitter menggunakan arsitektur mikroservis untuk memfasilitasi penskalaan horizontal dan pemisahan layanan. Setiap layanan memiliki kontrol atas model datanya sendiri dan sistem terbagi ke dalam beberapa layanan inti.

2. Layanan Pengguna:

Layanan ini menangani masalah pengguna seperti otentikasi dan informasi pengguna. Halaman Login, Daftar, Profil, dan Beranda akan ditangani oleh Layanan Pengguna.

3. Layanan Feed Berita:

Layanan ini bertanggung jawab atas pembuatan dan publikasi feed berita pengguna. Meskipun implementasinya sederhana, banyak faktor yang dapat mempengaruhi keberhasilan fitur ini.

4. Layanan Tweet:

Layanan ini menangani kasus pengguna terkait tweet seperti memposting, menandai favorit, dan lainnya.

5. Retweet:

Fitur Retweet diperlukan tambahan. Untuk mengimplementasikannya, tweet baru akan dibuat dengan ID pengguna yang melakukan retweet pada tweet asli.

6. Layanan Pencarian:

Bertanggung jawab atas fungsionalitas pencarian seperti mendapatkan postingan teratas dan terbaru berdasarkan peringkat.

7. Layanan Media:

Menangani unggahan media seperti gambar, video, dan file.

8. Layanan Analitik:

Digunakan untuk kasus penggunaan metrik dan analitik.

9. Algoritma Pemeringkatan:

Diperlukan untuk memeringkat setiap tweet sesuai relevansinya dengan pengguna tertentu.

10. Pencarian dengan Elasticsearch:

Menggunakan Elasticsearch untuk menyimpan, mencari, dan menganalisis volume data besar dengan cepat dan hampir real-time.

11. Identifikasi Trending Topic:

Fungsionalitas tren didasarkan pada fungsionalitas pencarian dengan menyimpan cache kueri, hashtag, dan topik yang paling sering dicari.

12. Layanan Notifikasi:

Pemberitahuan dorong diintegrasikan menggunakan antre pesan atau broker pesan seperti Apache Kafka dengan layanan pemberitahuan untuk mengirimkan permintaan ke Firebase Cloud Messaging (FCM) atau Apple Push Notification Service (APNS) untuk mengirimkan pemberitahuan dorong ke perangkat pengguna.

Model Data untuk Perancangan Sistem Twitter


Komentar