-
Notifications
You must be signed in to change notification settings - Fork 92
Affinitization: benefits, drawbacks, how to
Affinitization is when your requests are allocated to a specific Bungie.net server for all of your subsequent requests. Depending on your app, you may or may not want to affinitize.
Affinity is set by a cookie whose name and value rotates periodically. Previously we provided advice regarding searching for a cookie of a specific name and using/discarding it depending on your use case. This is no longer the recommended advice, as the name and potential values of this cookie can now change periodically and without notice.
Affinitization is useful in two situations:
- when your app is a single user app that provides rich interaction. If you're affinitized to a single server for - say - an Item Management app, then performing actions on items will properly bust the cache and show you the latest state of the user on subsequent requests.
In this situation, since the app is for a single user - and thus making requests on behalf of that single user for any given instance of the app - you're also making sure that your overall workload is still spread out across all of our servers (as one user with your app may be affinitized to a different server than another user with a separate instance of your app), which makes you a good citizen and less likely for us to have to block your access or throttle you. The way to be affinitized is to make sure that you are honoring any and all set-cookie headers that come back in responses by persisting cookies between requests. This will ensure that you're always consistently affinitized.
- If you're filtering requests through a proxy server/making batch requests/polling for live data, you will want to set up your connections to the API such that each user of your app ultimately uses a consistent affinitization cookie for subsequent requests.
The most straightforward way to do this is to store data about which of your own servers are requesting which user's data, and have request for that user's data always be done from the same server, and then to let that server honor affinitization cookies in the same manner as a client application would (i.e. honoring all set-cookie headers in the response, and passing cookies on in subsequent requests). Another alternative is to store all cookies when requesting data for a specific user on a per-user basis, and honoring set-cookie requests to alter the cookies you have stored when responses for that user's data contain new set-cookie headers in them. There are likely more scenarios you can envision depending on your architecture and needs.
If your app is making requests for PGCRs, you should call the endpoint through the stats.bungie.net domain. This will ensure that you are not affinitized, and will let us distribute the load: which will give you greater throughput to our servers as well as relieve some of our server stress.
In an ideal world, we would not have server affinitization at all. However, the API was originally designed for use by client applications that always accept and pass on cookies rather than server/batch access scenarios, and until we build in better support for this scenario affinitization is a reality in our API and unfortunately something that you'll have to consider when designing a batch processing/polling application.