上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
割り当ての計算を狂わせずにジオコーディング結果をキャッシュする
同じ住所を1週間に2回ジオコーディングするのはよくあるパターンで、キャッシュはその明らかな解決策です。つまずきやすいのは、キャッシュヒットとキャッシュミスがアプリケーションからはまったく同じに見えても、割り当てにとってはまったく違うということを忘れてしまう点です。
キャッシュしても安全なもの
ジオコーディングした住所はめったに変わらないため、正規化した入力をキーにして、ジオコーディングや逆ジオコーディングの結果全体を長期間キャッシュしても安全です。住所データの入れ替わりの多さに応じて、数週間から数か月が目安です。IP検索の結果は、IP範囲がときどき再割り当てされるため、より短い期間ならキャッシュしても安全です。タイムゾーン検索の識別子は安定していますが、utc_offset は夏時間によって変わるため、レスポンス全体を無期限にキャッシュするのではなく、識別子をキャッシュしてオフセットは再計算してください。
キャッシュから返しても割り当ては消費されない
キャッシュヒットとは、そのリクエストについてAPIをまったく呼び出していないということなので、X-Quota-Used にもクレジット残高にも何の変化もありません。それこそがキャッシュの目的ですが、同時に、キャッシュヒットは割り当てヘッダーのどこにも表れないということでもあります。割り当てヘッダーに反映されるのは、実際にAPIに届いた呼び出しだけです。キャッシュヒットを別に記録しているのでない限り、自分のリクエストカウンターを割り当てヘッダーと突き合わせようとしないでください。
キャッシュキーの例
cache_key = "forward:" + normalize("221B Baker Street, London")ハッシュ化する前に、小文字に変換し、前後の空白を取り除き、連続するスペースを1つにまとめて正規化してください。そうすれば、入力の些細な書式の違いによって不要なキャッシュミスが発生することはありません。
規模の見積もり
受け取る住所の半分がキャッシュ期間内の重複であれば、無料割り当てやプリペイドクレジットに対して実際に数えられるリクエスト数は、住所の総量のおよそ半分になります。すべてのキーに含まれる1日あたり2,500件の無料リクエストを超えてアップグレードが必要かどうかを判断する前に、これを知っておく価値があります。実際にAPIに届く数は、トラフィックの総量から想像されるよりもずっと少ないかもしれないからです。
キャッシュを使わないほうがよい場合
古い結果が明らかに誤りになるものについては、キャッシュを使わないでください。たとえば、顧客が修正したばかりの住所を再確認する場合です。新たな検索1回はどちらにしても1リクエストなので、特定の修正についてキャッシュを使わないことは、誤りとわかっているキャッシュ結果を返してしまうことを防ぐ安価な保険になります。
上手なキャッシュとは、すべてをキャッシュするか何もキャッシュしないかではなく、どのフィールドが安定していてどれがそうでないかを知ることに尽きます。キャッシュキーに適したフィールドについてはジオコーディングのドキュメントをご覧ください。