We should save each feature with a hash. For each district, we should save a hash so that, in the returned JSON, the user can validate if the current representative is the same as before. If not, then we should update. On app startup, this should be validated every single time. This also gives great traffic analytics into how often our app is opened and closed. Obviously, it can be pretty bad if some bot spam attacks it. Not looking forward to adding an IP throttle, but it will be done if necessary (in which case, the vote server already includes a caching functionality with Redis, so it's not difficult to implement either).
We can also use Cloudflare to protect ourselves from DOS attacks as an extra security measure if necessary. Hopefully, it's not necessary.
But the main point of this is for the user to know when they need to update. We can do that OR we can send a web hook to our server using a rotating key style SHA 512 hash saved on GitHub actions to hit our voting server to let users of district, state, and year blah to update by hitting the starlet server. I actually like that better. The voting Django backend can then let the user know on the next API request (regardless of path) to hit this starlet server.
Now, I don't particularly like the idea of "analytics" or "distributed internal throttling" (this excludes Cloudflare) since that ruins the integrity of privacy for our clients when it comes to exact location. On our backend server, we use django-ratelimit, but we only throttle based on user id, not on IP address (all our endpoints, except for our authorization endpoint obviously, require authorization. A better way of throttling would be to use the normalized user ID at our scale; in a larger scale, to catch a malicious actor trying to attack us via multiple actors, that's when Cloudflare or our internal throttling mechanism is necessary where django-ratelimit's user_or_ip
turns into our own user_and_ip
key).