從這篇文章來看 Tinder 的系統設計，以下是基礎的架構資訊：
- Tinder 完全 Host 在 AWS 上
- 使用了 AWS amplify 來建立和測試 iOS 和 Android
- 使用 MongoDB 作為 Database 和 Redis 作為 Cache
此篇文章只會探討於以下的功能：
- Login using OAuth (FB)
- Swipes (Left, Right)
- Matching
- chat
- push notification
- super likes
How recommendation algorithms work
這邊有提到了幾個 Tinder 如何實作推薦的方式。
- Active usage：會先看使用者的使用頻率，這個合理。沒什麼在使用的人就比較不推薦，但這樣有特別強調。不是登入次數，而是使用者如何使用應用程式
- Collect tags：當使用 Facebook 登入時，會搜集許多相關資料（很常見的資料，你懂的），有特別提到會抓取照片。我想應該會去做照片內容的分析。
- Group userbase：這邊是我覺得比較特別的，當使用者登入時，會從 tinder 得到一個隨機的分數，然後被分群在不同的 bucket（我就很好奇這分數是真的隨機，還是計算出來的）。
- Your pickiness/Bad actors：這裡提到的情境是，如果說你總是右滑，那就是會被頻蔽不被推薦。但我覺得這個案例，跟第一點滿想關的。個人覺得比較是如果有被檢舉之類的才比較是這一類別吧。
- Do you reply？：你在配對後有多主動回復
- Progressive taxation：這裡比較像是平衡機制，當一個人獲得太多關注或配對，就會降低這個人的推薦，反之亦然。
Recommendation Engine properties
- 低延遲：當登入到應用程序時，需要快速載入個人檔案/潛在匹配檔案。因此，我們的 RE 需要具有低延遲。
- 不是實時的：如果不是實時的也沒關係，即如果有人新加入 tinder，可以花一分鐘時間在 Tinder 上才顯示此人的個人資料。
- 易於 shard/distribute：由於我們擁有來自全球的大量個人資料，因此該推薦引擎應該能夠對資料進行 shard，因為我們無法將其保存在一個系統中。
- 全文搜索：我們需要搜索個人的整個個人資料，以提供更好的推薦
- HTTP interface：或 Web socket，用於獲取資料並將其發送到應用程式
- 資料結構：XML/JSON
這邊 Tinder 使用了 Elastic Search 來處理搜尋和排序資料的問題。
文章有提到兩個問題：
- 如何 shard 資料讓 elastic search 可以更快的搜尋
- 如何依照地理位址進行 shard 資料
How to shard data
Tinder 將使用者的地理位置分區，依照使用者的多寡和 active user 數量和 query 數量，對不同的區域作權重分配(使用 Google s2 library 來儲存資訊，這啥？)，並且查看這些地區的延遲和性能。
詳細的細節我就不贅述了，作者有畫了一些滿不錯的圖來講解。不想盜圖也懶得重畫，所以建議可以去作者那邊看看。
About matching
對於配對有三種情境：
- A 和 B 彼此右滑
- A 右滑 B，但是 B 沒有
- 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，這就滿需要考慮持久化了，不過想想好像也不是那麼重要，就算遺失了，配對不到也沒那麼重要，重要的是已經配對的不能消失。