TUGAS 4 - PPL A

 NAMA   : Ananda Hadi Saputra

KELAS  : PPL A

NRP       : 5025201148

High Level Design - Twitter

High Level Design

High Level Design (HLD) atau Desain tingkat tinggi  adalah gambaran umum dari suatu sistem atau aplikasi. HLD menjelaskan struktur dan arsitektur sistem secara keseluruhan, tanpa terpaku pada detail implementasi. HLD biasanya dibuat pada tahap awal pengembangan perangkat lunak, sebelum desain tingkat rendah (LLD) dibuat.

Persyaratan Sistem Desain Twitter

- Persyaratan Fungsional 

• Pengguna bisa posting tweet baru (text, gambar, video, dll)
• Pengguna bisa mengikuti pengguna lainnya
• Pengguna bisa mencari tweet pengguna lain
• Memiliki umpan berita yang terdiri dari twitter pengikut dari pengguna

- Persyaratan Non-Fungsional

• Ketersediaan tinggi dengan latensi rendah
• Sistem harus terukur dan efisien

- Persyaratan yang Diperpanjang

• Metrik dan Analitik
• Fungsi Retweet
• Tweet favorit

Perkiraan Kapasias Untuk Sistem Desain Twitter

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

Estimasi Lalu Lintas:

Misalkan kita memiliki 1 miliar pengguna total 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\text{ juta pengguna}\times 5\text{ tweet}=1\text{ miliar tweet/hari}$

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

$10\mathrm{\%}\times 1\text{ miliar}=100\text{ juta/hari}$

Untuk Permintaan Sistem per Detik (RPS) kita adalah:

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

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

Estimasi Penyimpanan:

Misalkan setiap pesan rata-rata berukuran 100 byte, kita akan membutuhkan sekitar 100 GB penyimpanan basis data setiap hari.

$1\text{ miliar}\times 100\text{ byte}=100\text{ GB/hari}$

10 persen dari pesan harian kita (100 juta) adalah file media sesuai persyaratan kita. Misalkan setiap file rata-rata berukuran 50KB, kita akan membutuhkan 5 TB penyimpanan setiap hari.

$100\text{ juta}\times 50\text{ KB}=5\text{ TB/hari}$

Untuk 10 tahun membutuhkan 19 PB penyimpanan.

$(5\text{ TB}+0,1\text{ TB})\times 365\text{ hari}\times 10\text{ tahun}=19\text{ PB}$

Estimasi Bandwidth:

Karena sistem kita menangani 5,1 TB data masuk setiap hari, kita akan membutuhkan bandwidth minimal sekitar 60 MB per detik.

$5,1\text{ TB}\mathrm{/}(24\text{ jam}\times 3600\text{ detik})=60\text{ MB/detik}$

Desain Use Case untuk Desain Sistem Twitter

Pada Diagram di atas,

Pengguna akan mengklik Halaman Twitter dan mereka akan mendapatkan halaman utama. Di dalam halaman utama, terdapat Halaman Beranda, Halaman Pencarian, dan Halaman Notifikasi.

• Di dalam Halaman Beranda, terdapat halaman Tweet Baru serta opsi untuk Memposting Gambar atau Video.
• Pada Tweet Baru, terdapat tombol untuk menyukai, tidak menyukai, memberikan komentar, serta mengikuti / berhenti mengikuti pengguna lain.
• Pengguna tamu hanya memiliki akses untuk melihat tweet apa pun.
• Pengguna terdaftar dapat melihat dan memposting tweet.
• Mereka dapat mengikuti dan berhenti mengikuti pengguna lain.
• Pengguna terdaftar dapat membuat tweet baru.

Desain Tingkat Tinggi (High Level Design) untuk Desain Sistem Twitter

1. Arsitektur:

Untuk Twitter, kami menggunakan arsitektur microservices karena akan memudahkan penskalaan horizontal dan memisahkan layanan kami. Setiap layanan akan memiliki model datanya sendiri. Kami akan membagi sistem kami menjadi beberapa layanan inti.

2. Layanan Pengguna:

Layanan ini menangani hal-hal terkait pengguna seperti otentikasi dan informasi pengguna. Halaman Login, Halaman Pendaftaran, Halaman Profil, dan Halaman Beranda akan ditangani oleh layanan Pengguna.

3. Layanan Newsfeed:

Layanan ini akan menangani pembuatan dan publikasi newsfeed pengguna.

4. Layanan Tweet:

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

5. Retweets:

Retweet adalah salah satu persyaratan tambahan kami. Untuk mengimplementasikan fitur ini, kami dapat membuat tweet baru dengan ID pengguna yang me-retweet tweet asli dan kemudian mengubah properti jenis enum dan konten tweet baru untuk menghubungkannya dengan tweet asli.

6. Layanan Pencarian:

Layanan ini bertanggung jawab untuk menangani fungsionalitas terkait pencarian. Dalam layanan pencarian, kita mendapatkan postingan teratas, postingan terbaru, dll. Hal ini kita dapatkan karena adanya peringkat.

7. Layanan Media:

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

8. Layanan Analitik:

Layanan ini akan digunakan untuk kasus penggunaan metrik dan analitik.

9. Algoritma Peringkat:

Kami memerlukan algoritma peringkat untuk memeringkat setiap tweet berdasarkan relevansinya dengan setiap pengguna tertentu.

10. Layanan Pencarian:

Terkadang DBMS tradisional tidak cukup performatif, kita memerlukan sesuatu yang memungkinkan kita menyimpan, mencari, dan menganalisis volume data yang besar dengan cepat dan hampir real-time serta memberikan hasil dalam milidetik. Elasticsearch dapat membantu kita dalam 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. Ini dibangun di atas Apache Lucene.

11. Layanan Notifikasi:

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

Data Model

Kesimpulan

Twitter menangani ribuan tweet per detik sehingga tidak memungkinkan untuk memiliki satu sistem besar atau tabel untuk menangani semua data. Oleh karena itu, data harus ditangani melalui pendekatan terdistribusi. Twitter menggunakan strategi "scatter and gather" di mana ia menyiapkan banyak server atau pusat data yang memungkinkan pengindeksan. Ketika Twitter menerima kueri (misalnya #geeksforgeeks), kueri tersebut dikirim ke semua server atau pusat data dan setiap shard Early Bird dijalankan. Semua Early Bird yang cocok dengan kueri mengembalikan hasilnya. Hasil-hasil ini kemudian dikembalikan, diurutkan, digabungkan, dan diulang peringkatnya. Peringkat dilakukan berdasarkan jumlah retweet, balasan, dan popularitas tweet.