#redis

Microsoft（Hotmail / Live / MSN / Outlook）宛てのメールだけが、SendGrid上で Deferred になった エラーは `451 4.7.650`。内容は「IP reputation を理由に一時的に rate limit した」というもの 筆者は最初、Microsoft側の障害や誤判定を疑った しかし調べるうちに、「急に多くのメールを送ったこと」が引き金ではないかと考え始めた 対策として、Redis を使った送信レート制限を実装し、Microsoft宛てのメールを 1 IP あたり毎分 10通までに抑えた その後、Microsoft側の担当者から制限レベルを調整したという返信があり、送信は復旧した 筆者の結論は、「Microsoftの判定が厳しかった可能性が高いが、送信側でもスパiky な配信を抑える仕組みが必要」というもの 元記事は、Microsoft系メールアドレスにだけメールが届かなくなったというトラブルの記録です。 ここでいう Microsoft 系とは、Hotmail、Live、MSN、Outlook など。昔からあるメール

REST APIが遅くなる最大の原因は、だいたいdatabaseアクセス Redisのような in-memory cache を使うと、読み込みをかなり速くできる Spring Bootでは `@EnableCaching` や `@CachePut`、`@CacheEvict` が実用的 更新時は「DBとcacheを同時に整える」設計が大事 人気データが一斉に失効すると cache stampede が起きるので、distributed lock で守る 最後は JMeter で load test して、ちゃんと速くなったか確認するのが重要 元記事の主張はかなりシンプルです。 高トラフィックなREST APIは、databaseアクセスがボトルネックになりやすい、という話です。 これは現場感としてもすごく納得感があります。 どんなにSQLを改善して、indexを貼って、ちょっと頑張っても、DBに毎回取りに行く構成だと限界が見えやすいんですよね。記事では、DBの応答が数百ミリ秒かかる一方で、Redisを使えばずっと速くなると説明しています。しかも、Redisはメモリ上で動くの