A student house is one IP address, so our rate limit counts licences

Notifio is a desktop application designed to monitor rental search listings and notify users via email when new listings emerge. The app operates by sending a request to a specific endpoint on the server, which then determines the appropriate response. The app itself does not store email credentials, as this information should remain confidential to the user. The focus of this discussion pertains to the endpoint and a specific line within it, which the author considers crucial to defend during a review.

The line "// Rate-limit per license (falling back to IP)" indicates the method used to limit the number of requests allowed per license. By keying the rate limit by license, the app assigns each user their own budget, even if they share the same IP address. This approach prevents users in shared accommodations, such as student houses, from competing against each other and inadvertently causing one user's requests to be blocked due to another user's activity.

The author argues that keying the limit by license token is a more appropriate choice for Notifio's target audience, which primarily consists of students and other users who typically share IP addresses.

The author provides an example of how the current implementation can lead to an unfair distribution of rate limits. In a scenario where six students are in a shared apartment and all are looking for housing at the same time, the sixth student's alert email would be blocked due to the shared IP address rate limit. By implementing a license-based rate limit, each student would have their own budget, ensuring that each receives their alert email without interference from their housemates.

This approach aligns with the author's goal of protecting the app from being overwhelmed by a single license's suspicious volume of mail while allowing multiple users to operate within their separate budgets.

The author emphasizes the importance of separating the rate limit counters for different endpoints, such as /api/validate and /api/notify. By doing so, the app can prevent a burst of validation requests from consuming the budget allocated for sending notifications. This separation ensures that both features operate independently and effectively without competing against each other for limited resources.

The author concludes by highlighting the significance of this line in the endpoint's code, emphasizing its role in maintaining a fair and efficient rate limiting system for Notifio's users.