{"id":1936,"date":"2021-01-20T01:43:07","date_gmt":"2021-01-19T20:13:07","guid":{"rendered":"https:\/\/judepereira.com\/blog\/?p=1936"},"modified":"2021-01-20T01:43:08","modified_gmt":"2021-01-19T20:13:08","slug":"taming-a-throttled-api-with-dynamic-proxies-in-java","status":"publish","type":"post","link":"https:\/\/judepereira.com\/blog\/taming-a-throttled-api-with-dynamic-proxies-in-java\/","title":{"rendered":"Taming a throttled API with Dynamic Proxies in Java"},"content":{"rendered":"\n

Recently, at CleverTap<\/a>, we’ve begun migrating some of our largest clusters to a new protocol (for starters, think ~115 instances at a time). One of the most fun things I’ve had my hands on during this migration was the AWS Systems Manager API.<\/p>\n\n\n\n

When we scaled up our migrations gradually from a 10 node cluster, we were challenged with dealing with API throttling exceptions (because sure, who wouldn’t throttle their APIs?). There were two immediate solutions that hit our mind:<\/p>\n\n\n\n

  1. Review every usage of the SSM client and handle the throttling exception gracefully<\/li>
  2. Wrap the SSM client and handle the throttling exception transparently<\/li><\/ol>\n\n\n\n

    Naturally, we settled for option 2. I am a big fan of hidden abstractions. So what did we do? We implemented the AWS interface in question, only to discover that we’d have to handle a ton of methods individually (obviously copy\/paste). There had to be a better solution!<\/p>\n\n\n\n

    And then, Google did it’s thing. We discovered Dynamic Proxies<\/strong><\/a>. And viola! We were able to transparently handle and implement an auto retry strategy within just 14 lines<\/strong>!<\/p>\n\n\n\n

    Here’s what it looked like:<\/p>\n\n\n\n

    \n