知識閱讀 - Tinder 的系統設計

從這篇文章來看 Tinder 的系統設計，以下是基礎的架構資訊：

1. Tinder 完全 Host 在 AWS 上
2. 使用了 AWS amplify 來建立和測試 iOS 和 Android
3. 使用 MongoDB 作為 Database 和 Redis 作為 Cache

此篇文章只會探討於以下的功能：

1. Login using OAuth (FB)
2. Swipes (Left, Right)
3. Matching
4. chat
5. push notification
6. super likes

How recommendation algorithms work

這邊有提到了幾個 Tinder 如何實作推薦的方式。

1. Active usage：會先看使用者的使用頻率，這個合理。沒什麼在使用的人就比較不推薦，但這樣有特別強調。不是登入次數，而是使用者如何使用應用程式
2. Collect tags：當使用 Facebook 登入時，會搜集許多相關資料（很常見的資料，你懂的），有特別提到會抓取照片。我想應該會去做照片內容的分析。
3. Group userbase：這邊是我覺得比較特別的，當使用者登入時，會從 tinder 得到一個隨機的分數，然後被分群在不同的 bucket（我就很好奇這分數是真的隨機，還是計算出來的）。
4. Your pickiness/Bad actors：這裡提到的情境是，如果說你總是右滑，那就是會被頻蔽不被推薦。但我覺得這個案例，跟第一點滿想關的。個人覺得比較是如果有被檢舉之類的才比較是這一類別吧。
5. Do you reply？：你在配對後有多主動回復
6. Progressive taxation：這裡比較像是平衡機制，當一個人獲得太多關注或配對，就會降低這個人的推薦，反之亦然。

Recommendation Engine properties

1. 低延遲：當登入到應用程序時，需要快速載入個人檔案/潛在匹配檔案。因此，我們的 RE 需要具有低延遲。
2. 不是實時的：如果不是實時的也沒關係，即如果有人新加入 tinder，可以花一分鐘時間在 Tinder 上才顯示此人的個人資料。
3. 易於 shard/distribute：由於我們擁有來自全球的大量個人資料，因此該推薦引擎應該能夠對資料進行 shard，因為我們無法將其保存在一個系統中。
4. 全文搜索：我們需要搜索個人的整個個人資料，以提供更好的推薦
5. HTTP interface：或 Web socket，用於獲取資料並將其發送到應用程式
6. 資料結構：XML/JSON

這邊 Tinder 使用了 Elastic Search 來處理搜尋和排序資料的問題。

文章有提到兩個問題：

1. 如何 shard 資料讓 elastic search 可以更快的搜尋
2. 如何依照地理位址進行 shard 資料

How to shard data

Tinder 將使用者的地理位置分區，依照使用者的多寡和 active user 數量和 query 數量，對不同的區域作權重分配(使用 Google s2 library 來儲存資訊，這啥？)，並且查看這些地區的延遲和性能。

詳細的細節我就不贅述了，作者有畫了一些滿不錯的圖來講解。不想盜圖也懶得重畫，所以建議可以去作者那邊看看。

About matching

對於配對有三種情境：

1. A 和 B 彼此右滑
2. A 右滑 B，但是 B 沒有
3. B 右滑 A，A 沒有右滑直到現在

配對服務跟推薦的分區類似，但是會是範圍更大。例如一個配對服務的分區，可能是 10 個推薦分區的大小。這邊雖然提到不同國家間不會配對，只會發生在有推薦給使用者的推薦分區，但是這文章是 2020 的，記得現在 Tinder 因為疫情現在是可以跨國的，所以可能狀況不太一樣了。

當 A 右滑 B 的時候，會送訊息到 Kafka，然後 Kafka consumer 會將其狀態存到 Reids，類似一個 Key A_B。然後去找找看 B 有沒有右滑 A 過，如果有的話應該可以找的 B_A，沒有的話則略過。如果 B_A 存在，就代表配對成功，就會送出 matched queue，利用 web socket 送出配對成功的通知。

這邊有點像似一個 in-memory database，這就滿需要考慮持久化了，不過想想好像也不是那麼重要，就算遺失了，配對不到也沒那麼重要，重要的是已經配對的不能消失。

Reference

• Tinder System Design