Tugas Pertemuan 5 PPL

Nama : Frederick Yonatan Susanto

NRP : 5025211121

Kelas : PPL A

Tahun Ajaran : 2023/2024 (Genap)

    Pada pertemuan kelima di kelas PPL A, kita diminta untuk berlatih membuat dan menganalisis high-level design (HLD)  dari sistem aplikasi Twitter berdasarkan video YouTube berikut:

Video yang saya gunakan yaitu "Design Twitter - System Design Interview".


High Level Design Twitter

A. Deskripsi Singkat

    Pada tahap awal dalam merancang arsitektur sistem secara keseluruhan, High-Level Design Twitter melibatkan pengidentifikasian serta pemodelan komponen-komponen utama dan interaksi di antara mereka. Fokusnya terutama pada aspek besar sistem seperti komponen utama, interaksi, skalabilitas, keandalan, keamanan, dan performa. Ini merupakan dasar untuk tahap selanjutnya, yaitu Detailed Design, di mana setiap komponen dan interaksi akan diuraikan lebih rinci untuk memungkinkan fokus pada aspek teknis dan implementasi berdasarkan arsitektur yang telah ditetapkan sebelumnya.

B. System Requirements

a. Persyaratan Fungsional:
  • Memungkinkan pengguna untuk membuat postingan baru yang dapat berupa teks, gambar, video, dan sebagainya.
  • Memungkinkan pengguna untuk mengikuti pengguna lain.
  • Menyediakan fitur umpan berita yang terdiri dari tweet dari pengguna yang diikuti.
  • Memungkinkan pengguna untuk melakukan pencarian tweet

b. Persyaratan Non Fungsional:
  • Memiliki ketersediaan yang tinggi dengan latensi minimal.
  • Sistem harus dapat diukur dan efisien.

c. Persyaratan yang Diperpanjang:
  • Menyediakan metrik dan analitik untuk melacak kinerja dan penggunaan sistem.
  • Menyediakan fungsi retweet untuk memperbanyak distribusi tweet.
  • Memungkinkan pengguna untuk menandai tweet sebagai favorit untuk menyimpannya.

C. Estimasi Kapasitas Perancangan Sistem Twitter

a. Estimasi Lalu Lintas

    Contoh, jika terdapat 1 miliar pengguna secara keseluruhan, di antaranya terdapat 200 juta pengguna yang aktif setiap hari (DAU), dan dengan rata-rata setiap pengguna melakukan 5 postingan tweet setiap hari, maka akan dihasilkan total 1 miliar tweet setiap hari.

200 million * 5 tweets = 1 billion/day


    Tweet juga mencakup media seperti gambar atau video. Misalkan, 10% dari total tweet merupakan file media yang dibagikan oleh pengguna. Dengan demikian, tambahan 100 juta file media perlu disimpan.

10 percent * 1 billion = 100 million/day

    Untuk menghitung permintaan sistem per detik (RPS) adalah:

1 billion requests per day translate into 12K requests per second.

1 billion / (24 hrs * 3600 seconds) = 12K requests/second


b. Estimasi Penyimpanan

    Dengan asumsi bahwa setiap pesan memiliki ukuran rata-rata sebesar 100 byte, maka total penyimpanan yang dibutuhkan untuk menyimpan 1 miliar tweet per hari adalah sekitar 100 GB.

100 billion * 100 bytes = 100 GB/day

    Dari total pesan harian, 10 persen diantaranya berupa file media. Dengan asumsi bahwa rata-rata ukuran setiap file media adalah 50 KB, maka diperlukan penyimpanan sebesar 5 TB setiap harinya.

100 million * 50 KB = 5TB/day

    Dalam periode 10 tahun, diperlukan penyimpanan sebesar 19 PB.

(5TB + 0.1 TB ) * 365 days * 10 years = 19 PB

c. Estimasi Bandwidth

    Dengan sistem yang menangani masukan sebesar 5,1 TB setiap hari, dibutuhkan bandwidth minimum sekitar 60 MB per detik.

5.1 TB / (24 hrs * 3600 seconds) = 60 MB/second

C. System Design

System Design untuk Twitter:


    Ketika tweet dibuat, panggilan API mencapai load balancer, dan kemudian panggilan tersebut mencapai Twitter writer. Twitter writer mengirim salinan tweet ke database, Apache storm (untuk menganalisis trending hashtags), fanout service (untuk memperbarui timeline), dan search service (untuk indexing).

    Jika pengguna ingin mencari sesuatu, sebuah panggilan API dibuat ke load balancer, dan kemudian permintaan tersebut diteruskan ke timeline service. Panggilan tersebut kemudian dipindahkan ke search service, di mana operasi pencarian dilakukan dengan efisien menggunakan strategi scatter and gather. Demikian pula, ketika pengguna meminta home timeline atau user timeline, permintaan mencapai timeline service, yang langsung mengakses Redis. Redis menentukan timeline yang sesuai dan mengembalikan hasil dalam format JSON (JavaScript Object Notation).

    HTTP push WebSocket bertanggung jawab atas penanganan koneksi real-time dengan aplikasi. Layanan ini harus mampu menangani jutaan koneksi pada setiap titik waktu tertentu.

    ZooKeeper adalah layanan coordination service yang sangat andal untuk distributed components. Twitter menjalankan ribuan nodes dalam setiap cluster yang diberikan untuk Redis. Sebagian besar data disimpan di Redis dalam big clusters, yang memerlukan coordination antara nodes. Ini juga melacak server mana yang online/offline dan coordinates antara nodes tersebut secara sesuai.

D. Low Level Design and High Level Design

a. Low Level Design for Twitter System Design



1. Penyimpanan Data:
  • Data pengguna disimpan dalam database relasional seperti MySQL, termasuk informasi seperti nama pengguna, email, password (hashed), foto profil, dan biodata.
  • Tweet disimpan dalam tabel terpisah dalam database yang sama, mencakup konten tweet, ID penulis, timestamp, tagar, mention, retweet, balasan, dan lainnya.
  • Hubungan pengikut dan diikuti direpresentasikan dalam tabel terpisah untuk mengizinkan pengambilan umpan pengguna dengan efisien.
  • Aset media seperti gambar atau video disimpan dalam sistem penyimpanan yang didedikasikan seperti S3, dengan referensi dalam tabel tweet.

2. Fungsionalitas Inti:

Posting a tweet:
  • Pengguna mengirimkan konten tweet melalui antarmuka pengguna.
  • Validasi sisi server memeriksa panjang tweet, ukuran media, dan batasan lainnya.
  • Data tweet disimpan dalam database dengan asosiasi yang relevan seperti tagar, mention, dan balasan.
  • Notifikasi real-time dikirimkan ke pengikut dan pengguna yang disebutkan.
Timeline generation:
  • Daftar pengguna dan tagar yang diikuti oleh pengguna saat ini diambil.
  • Tweet terbaru dari pengguna-pengguna tersebut dan tagar-tagar yang cocok diambil dari database.
  • Algoritma digunakan untuk meranking tweet berdasarkan relevansi, ketepatan waktu, keterlibatan, dll.
  • Timeline yang sering diakses disimpan dalam Redis untuk pengiriman yang lebih cepat.
Search:
  • Pengguna memasukkan kata kunci atau tagar.
  • Pencarian sisi server menganalisis konten tweet, tagar, dan metadata pengguna.
  • Tweet yang relevan dikembalikan berdasarkan algoritma perankingan.
    Follow/unfollow:
  • Tabel hubungan mengikuti diperbarui sesuai dengan tindakan pengguna.
  • Notifikasi yang relevan dipicu dan timeline pengguna disesuaikan secara dinamis.


b. High Level Design for Twitter System Design



Kita dapat membagi layanan pada sistem aplikasi Twitter menjadi beberapa layanan berikut:

  • Arsitektur: Twitter menggunakan arsitektur layanan mikro untuk memudahkan penskalaan horizontal dan memisahkan layanan. Setiap layanan memiliki kepemilikan atas model datanya sendiri.
  • Layanan Pengguna: Menangani masalah terkait pengguna seperti otentikasi dan informasi pengguna. Halaman Login, Pendaftaran, Profil, dan Beranda akan ditangani dalam layanan ini.
  • Layanan Umpan Berita: Bertanggung jawab atas pembuatan dan penerbitan umpan berita pengguna, termasuk fitur-fitur terkait newsfeed dengan kompleksitas tertentu.
  • Layanan Tweet: Menangani interaksi terkait tweet seperti memposting, menandai sebagai favorit, dan lainnya.
  • Retweet: Implementasi fitur tambahan untuk me-retweet tweet asli dengan membuat tweet baru yang terhubung dengan tweet asli.
  • Layanan Pencarian: Bertugas menangani fungsi pencarian termasuk penyajian postingan teratas dan terbaru berdasarkan relevansi.
  • Layanan Media: Menangani unggahan media seperti gambar, video, dan file.
  • Layanan Analisis: Digunakan untuk memantau metrik dan analitik terkait penggunaan platform.
  • Algoritma Pemeringkatan: Menggunakan algoritma kompleks untuk memberi peringkat pada setiap tweet berdasarkan faktor-faktor seperti kedekatan pengguna, bobot interaksi, dan peremajaan.
  • Layanan Notifikasi: Mengirimkan pemberitahuan kepada pengguna menggunakan sistem antrian pesan dan layanan notifikasi push seperti Firebase Cloud Messaging.

E. Data Model Design

Perancangan Model Data untuk Perancangan Sistem Twitter



Penjelasan:
  • user_details: Atribut ini mungkin berisi detail pengguna seperti nama, alamat email, atau informasi lainnya terkait profil pengguna.
  • screen_name: Ini adalah nama layar atau alias yang digunakan oleh pengguna Twitter.
  • screen name created date: Tanggal pembuatan akun pengguna.
  • location: Lokasi geografis pengguna.
  • twitter url: URL atau tautan ke profil pengguna di Twitter.
  • usc_name: Mungkin ini adalah atribut yang salah ketik atau tidak jelas.
  • user_tweet_mention: Kemungkinan mencatat interaksi antara pengguna dan tweet yang menyebut atau mengutip pengguna tertentu.
  • screen name tweet id: ID tweet yang terkait dengan nama layar pengguna tertentu.
  • mention reen name: Nama layar yang disebutkan dalam tweet.
  • tweets_user_counter: Jumlah tweet yang diposting oleh pengguna.
  • friend_count: Jumlah teman atau pengguna yang diikuti oleh pengguna.
  • follower_count: Jumlah pengikut atau pengguna yang mengikuti pengguna.
  • follower list: Daftar pengguna yang mengikuti pengguna tertentu.
  • follower_details: Detail tentang pengikut pengguna tertentu, mungkin termasuk nama, lokasi, atau informasi lainnya.
  • Fiend list: Daftar teman pengguna tertentu.
  • tweets_information: Informasi terkait tweet, seperti tanggal publikasi, tautan, atau teks tweet.
  • tweets_user_day: Jumlah tweet yang diposting oleh pengguna dalam satu hari.
  • tweets month: Jumlah tweet yang diposting oleh pengguna dalam satu bulan.
  • tweets_day: Jumlah tweet yang diposting dalam satu hari tertentu.
  • tweet mention: Informasi tentang tweet yang menyebut atau mengutip pengguna tertentu.
  • tweet_hachtag: Informasi tentang hashtag yang terkait dengan tweet.
  • tweet_urt: URL yang terkait dengan tweet.
  • tweet_id: ID unik untuk tweet.
  • tweets_user_month: Jumlah tweet yang diposting oleh pengguna dalam satu bulan.
  • user_tweet_hashtag: Informasi tentang hashtag yang terkait dengan tweet pengguna.

F. Conclusion

    Twitter menangani ribuan tweet per detik dengan menggunakan pendekatan terdistribusi, yang berarti tidak hanya ada satu sistem atau tabel besar yang menangani semua data. Sebaliknya, Twitter menggunakan strategi sebar dan kumpulkan dengan menyediakan beberapa server atau pusat data yang memungkinkan pengindeksan.

    Manfaat dari pembuatan high-level design pada sistem desain Twitter adalah memberikan pandangan yang komprehensif tentang arsitektur sistem secara keseluruhan. Ini memungkinkan tim pengembangan untuk memahami struktur sistem dengan jelas, merencanakan solusi yang memenuhi kebutuhan fungsional dan non-fungsional, serta berkomunikasi dengan efektif kepada anggota tim dan pemangku kepentingan.

    Dengan pemahaman yang mendalam tentang alur kerja sistem, perencanaan yang terstruktur, dan identifikasi risiko awal, High-Level Design mendukung pengambilan keputusan yang tepat, kesesuaian dengan kebutuhan bisnis, dan perencanaan skalabilitas yang terorganisir. Hal ini memastikan pengembangan sistem berjalan secara efisien dan menghasilkan produk akhir yang berkualitas tinggi.


Daftar Pustaka



Comments

Popular posts from this blog

Tugas Pertemuan 7 PPL

Quiz 1 PBKK A

Tugas Pertemuan 6 PPL