SYSTEM DESIGN INTERVIEW Chapter10 DESIGN A NOTIFICATION SYSTEMの感想・まとめ
こんにちは。今回もSYSTEM DESIGN INTERVIEWを読んだので、感想を書いていきたいと思います。今回は通知サービスです。
前回の投稿はこちらです。
概要
通知サービスは過去に何度か実装したことがあるので、復習がてら自分の過去の実装は間違っていないか？を確認することができました。(記述のサマリはあまり特筆すべきものなかったので省略します)
今だと、スマホ前提でPush通知だけかな？と思ったら、SMSやメールサービスもあるのでそれらを対象にしたPUSH通知をどうやって作るか？というのはあまり考えたことがなかったのでよかったです。(とはいえ、各種外部プロバイダーに頼るので、特定の技術の説明はほとんどありませんでしたが
あとPUSH通知だと、Appleさんが送られることは保証されないから必ず送らないといけない内容のものは他の手段で送ってねーと言ってるのであんまり気にしたことがなかったのですが、そこにメールも対象にするなら到達保証をする必要があるので、そこの仕組み構築は確かに必要だなと。
Because the delivery of remote notifications is not guaranteed, never include sensitive data or data that can be retrieved by other means in your payload
通知のオプトインの仕組みも開発に携わったことあるので割と仕組みとしてはここで言及されるようなものはやったことあるなぁと感じました。
所感
あまり新しい知識を得るということはできませんでしたが、やったことがあからさまに間違っていなことは確認できたのでホッとしました。
PUSH通知関連で前見た記事で面白かったのは、メルカリさんの記事でした。
大量のユーザーがいるときの一斉PUSH通知なんかは逆にAPIサーバーやDBの負荷を懸念して、緩い時間で行うというのは面白い視点だなと。なかなか考える機会がないのでそこまでのサービス規模のサービスに携わる際は考えていきたいです。
実際には workers や pusher_max の値やGaurunのサーバ台数を調整することでもっと短い時間で完了することも可能ですが、あんまり早くプッシュし過ぎるとAPIサーバやDBサーバに負荷がかかってしまうのであえて台数やパラメータは抑えめにしています。