ernah memikirkan bagaimana sebenarnya aplikasi perpesanan yang banyak digunakan ini bekerja di balik layar? Artikel ini adalah panduan Anda tentang desain sistem WhatsApp. Dari menangani banyak pesan hingga memastikan obrolan Anda aman, kami akan mengeksplorasi aspek teknis yang membuat aplikasi ini berjalan lancar dan mengelola hal-hal seperti mengelola data, menjaga privasi pesan Anda, dan tantangan untuk memastikan pesan teks Anda tiba secepat kilat.

Persyaratan

Desain messenger WhatsApp harus memenuhi persyaratan di bawah ini:

Persyaratan Fungsional

• Percakapan : Sistem harus mendukung percakapan satu lawan satu dan kelompok antar pengguna.
• Acknowledgment : Sistem harus mendukung pengakuan pengiriman pesan, seperti terkirim, terkirim, dan dibaca.
• Berbagi : Sistem harus mendukung berbagi file media, seperti gambar, video, dan audio.
• Penyimpanan obrolan : Sistem harus mendukung penyimpanan pesan obrolan secara persisten saat pengguna offline hingga pengiriman pesan berhasil.
• Pemberitahuan push : Sistem harus dapat memberi tahu pengguna offline tentang pesan baru setelah status mereka online.
  
  

  Persyaratan Non-Fungsional

  • Latensi rendah: Pengguna harus dapat menerima pesan dengan latensi rendah.
  • Konsistensi : Pesan harus disampaikan sesuai urutan pengirimannya.
  • Ketersediaan : Sistem harus sangat tersedia. Namun, ketersediaannya dapat dikompromikan demi kepentingan konsistensi.
  • Keamanan: Sistem harus aman melalui enkripsi ujung ke ujung. Enkripsi ujung ke ujung memastikan bahwa hanya dua pihak yang berkomunikasi dapat melihat isi pesan. Tak seorang pun di antara keduanya, bahkan WhatsApp, boleh memiliki akses.
  • Skalabilitas : Sistem harus memiliki skalabilitas yang tinggi untuk mendukung jumlah pengguna dan pesan yang terus meningkat setiap harinya.

  Estimasi Kapasitas

  Estimasi Penyimpanan :

  100 miliar pesan dibagikan melalui WhatsApp per hari dan setiap pesan rata-rata membutuhkan 100 byte
  100 miliar/hari?100 Byte = 10 TB/hari
  Selama 30 hari, kapasitas penyimpanan akan menjadi sebagai berikut:
  30?10 TB/hari = 300 TB /bulan

  Estimasi Bandwidth :

  Menurut perkiraan kapasitas penyimpanan, layanan kami akan mendapatkan 10TB data setiap hari, sehingga memberi kami bandwidth sebesar 926 Mb/s.
  10TB/86400dtk ? 926Mb/dtk

  Estimasi jumlah server:

  WhatsApp menangani sekitar 10 juta koneksi pada satu server, yang tampaknya cukup tinggi untuk sebuah server.
  Jumlah server = Total koneksi per hari/No. koneksi per server = 2 miliar/10 juta = 200 server
  Jadi, menurut perkiraan di atas, kami memerlukan 200 server chat.

  Desain Tingkat Tinggi (HLD) WhatsApp Messenger

  
  

Langkah-langkah berikut menjelaskan komunikasi antara kedua klien:

• Pengguna A dan pengguna B membuat saluran komunikasi dengan server obrolan.
• Pengguna A mengirim pesan ke server obrolan.
• Setelah menerima pesan, server obrolan membalas ke pengguna A.
• Server chat mengirimkan pesan ke pengguna B dan menyimpan pesan tersebut ke database jika status penerima sedang offline.
• Pengguna B mengirimkan pengakuan ke server obrolan.
• Server obrolan memberi tahu pengguna A bahwa pesan telah berhasil terkirim.
• Ketika pengguna B membaca pesan tersebut, aplikasi memberi tahu server obrolan.
• Server obrolan memberi tahu pengguna A bahwa pengguna B telah membaca pesan tersebut.

Desain Model Data:

• users: Tabel ini akan berisi informasi pengguna seperti nama, nomor telepon, dan detail lainnya.
• messages: Tabel ini akan menyimpan pesan dengan properti seperti jenis (teks, gambar, video, dll.), konten, dan stempel waktu pengiriman pesan. Pesan tersebut juga akan memiliki chatID atau groupID yang sesuai.
• obrolan : Tabel ini pada dasarnya mewakili obrolan pribadi antara dua pengguna dan dapat berisi banyak pesan.
• users_chats : Tabel ini memetakan pengguna dan obrolan karena banyak pengguna dapat melakukan banyak obrolan (hubungan N:M) dan sebaliknya.
• groups : Tabel ini mewakili grup antara beberapa pengguna.
• users_groups : Tabel ini memetakan pengguna dan grup karena beberapa pengguna dapat menjadi bagian dari beberapa grup (hubungan N:M) dan sebaliknya.

Desain API

Send message

sendMessage

(ID_pesan, ID_pengirim, ID_penerima, ketik, teks=tidak ada, objek_media=tidak ada, dokumen=tidak ada)

API ini digunakan untuk mengirim pesan teks dari pengirim ke penerima dengan melakukan panggilan POST API ke endpoint /messages API. Umumnya, ID pengirim dan penerima adalah nomor telepon mereka.

Get Message

getMessage(ID_pengguna)

Dengan menggunakan panggilan API ini, pengguna dapat mengambil semua pesan yang belum dibaca saat mereka online setelah offline selama beberapa waktu.

Upload File

uploadFile

(tipe_file, file)

Kita dapat mengunggah file media melalui uploadFile API dengan membuat permintaan POST ke endpoint /v1/media API. Respons yang berhasil akan mengembalikan ID yang diteruskan ke penerima.

Unduh File Media

unduhFile(user_id, file_id)

Arsitektur

Kami akan menggunakan arsitektur layanan mikro karena ini akan mempermudah penskalaan horizontal dan memisahkan layanan kami. Setiap layanan akan memiliki kepemilikan atas model datanya sendiri.

Desain Tingkat Rendah (LLD) Desain Sistem

1. Koneksi dengan Server Websocket

Di WhatsApp, setiap perangkat aktif terhubung dengan server WebSocket melalui protokol WebSocket. Server WebSocket menjaga koneksi tetap terbuka dengan semua pengguna aktif (online). Karena satu server tidak cukup untuk menangani miliaran perangkat, server harus cukup untuk menangani miliaran pengguna.

Tanggung jawab masing-masing server ini adalah menyediakan port untuk setiap pengguna online. Pemetaan antara server, port, dan pengguna disimpan di manajer WebSocket yang berada di atas cluster penyimpanan data. Dalam hal ini, itulah Redis.

2. Mengirim atau menerima pesan

Manajer WebSocket bertanggung jawab untuk memelihara pemetaan antara pengguna aktif dan port yang ditetapkan untuk pengguna tersebut. Setiap kali pengguna terhubung ke server WebSocket lain, informasi ini akan diperbarui di penyimpanan data. Server WebSocket juga berkomunikasi dengan layanan lain yang disebut layanan pesan.

Layanan pesan adalah tempat penyimpanan pesan di atas cluster database Mnesia. Ini bertindak sebagai antarmuka ke database Mnesia untuk layanan lain yang berinteraksi dengan database. Ini bertanggung jawab untuk menyimpan dan mengambil pesan dari database Mnesia. Itu juga menghapus pesan dari database Mnesia setelah jangka waktu yang dapat dikonfigurasi. Dan, hal ini memaparkan API untuk menerima pesan dengan berbagai filter, seperti ID pengguna, ID pesan, dan sebagainya.

3. Mengirim atau menerima file media

Kami memiliki layanan lain yang disebut layanan aset, yang bertanggung jawab untuk mengirim dan menerima file media.

• File media dikompresi dan dienkripsi di sisi perangkat.
• File terkompresi dan terenkripsi dikirim ke layanan aset untuk menyimpan file di penyimpanan blob.
• Layanan aset memberikan ID yang dikomunikasikan dengan pengirim. Layanan aset juga mempertahankan hash untuk setiap file untuk menghindari duplikasi konten pada penyimpanan blob.
  • Misalnya, jika pengguna ingin mengunggah gambar yang sudah ada di penyimpanan blob, gambar tersebut tidak akan diunggah. Sebaliknya, ID yang sama diteruskan ke penerima.
• Layanan aset mengirimkan ID file media ke penerima melalui layanan pesan. Penerima mengunduh file media dari penyimpanan blob menggunakan ID.
• Konten dimuat ke CDN jika layanan aset menerima sejumlah besar permintaan untuk konten tertentu.

4. Dukungan untuk pesan Grup

Karena pengguna A terhubung ke server WebSocket, ia mengirimkan pesan ke layanan pesan yang ditujukan untuk Grup A. Layanan pesan mengirimkan pesan ke Kafka dengan informasi spesifik lainnya tentang grup tersebut. Pesan tersebut disimpan di sana untuk diproses lebih lanjut. Dalam terminologi Kafka, grup dapat menjadi sebuah topik, dan pengirim serta penerima masing-masing dapat menjadi produsen dan konsumen.

Sekarang, inilah tanggung jawab pelayanan kelompok. Layanan grup menyimpan semua informasi tentang pengguna di setiap grup dalam sistem. Ia memiliki semua informasi tentang setiap grup, termasuk ID pengguna, ID grup, status, ikon grup, jumlah pengguna, dan sebagainya. Layanan ini berada di atas cluster database MySQL, dengan beberapa replika sekunder yang didistribusikan secara geografis. Server cache Redis juga tersedia untuk menyimpan data dari server MySQL. Replika yang terdistribusi secara geografis dan cache Redis membantu mengurangi latensi.

Pengendali pesan grup berkomunikasi dengan layanan grup untuk mengambil data pengguna Grup/A. Pada langkah terakhir, pengendali pesan grup mengikuti proses yang sama seperti server WebSocket dan mengirimkan pesan ke setiap pengguna.

Pendekatan untuk mencapai atribut sistem di bawah ini

Persyaratan Non-fungsional	Pendekatan
Meminimalkan latensi	Sistem dan server manajemen cache yang terdistribusi secara geografis CDN
Konsistensi	Berikan ID unik ke pesan menggunakan Sequencer atau mekanisme lainnya Gunakan antrian pesan FIFO dengan urutan yang ketat
Ketersediaan	Menyediakan beberapa server dan pengelola WebSocket untuk membangun koneksi antar pengguna Replikasi pesan dan data yang terkait dengan pengguna dan grup di server berbeda Ikuti protokol pemulihan bencana
Keamanan	Melalui enkripsi ujung ke ujung
Skalabilitas	Penyetelan kinerja server Skalabilitas layanan horizontal

Merasa tersesat di dunia Desain Sistem yang luas? Saatnya untuk transformasi! Daftarkan diri kami dalam Desain Sistem Penguasaan Dari Solusi Tingkat Rendah hingga Tingkat Tinggi - Kursus Langsung dan mulailah perjalanan yang mengasyikkan untuk menguasai konsep dan teknik desain sistem secara efisien.
Apa yang kita tawarkan:

• Cakupan Kursus Komprehensif
• Panduan Ahli untuk Pembelajaran yang Efisien
• Pengalaman Langsung dengan Proyek Desain Sistem Dunia Nyata
• Rekam Jejak Terbukti dengan 100.000+ Penggemar Sukses