When managing large-scale services, there are always unexpected cases to handle during batch operations.
Many of these issues happen because there are no proper limits for users.
Recently, I faced a problem with an abusing user.
I manage a service which syncs schedules.
During a batch operation, we found a user with over a million schedules.
Considering that recurring schedules (like ‘weekly meeting at 10 AM every Tuesday’) count as just one schedule, this wasn’t a normal usecase.
- They even created 1,000 schedules in just 10 minutes.
This forced us to spend time and effort modifying the batch logic and changing the instance type.
One thing I’ve always found lacking in our company’s services is the lack of policies for such limits.
Looking at APIs from Instagram and Facebook made me reflect on this issue.
When it comes to applying limits effectively, Instagram is a great example. it’s easy to understand too.
Instagram's policy on inauthentic activity and spam1 explains that these activities harm both users and the service.
Fake activities degrade the quality of the service and damage the community.
I guess this policy was developed because spam was a big issue. In my thought, in Facebook’s early days spam could makes users left the platform.
Fake activities not only make managing the service harder but also lower its quality, which Facebook seems to recognize as a serious problem.
Instagram sets clear limits for both users and APIs.
Limits for Users
| Action | Limit |
|---|---|
| Following people | 7,500 accounts |
| Likes | 120 per hour, 300-500 per day |
| Comments | 200 per day |
| Tagging people | 20 per post |
| Direct Messages | 50-70 per day |
The limits vary based on trustworthiness (e.g., accounts older than six months),
but they have overall limits and per-hour or per-day restrictions.
Except for the following limit2, other policies are mostly unofficial3. You can find them mentioned in many sources, though not directly announced by Instagram.
This may be because the limitations of these policies do not affect the real user.
Limits for APIs
For developers, Instagram’s API limits creating posts to 50 per day4.
Interestingly, Facebook tracks and shares metrics5 on abuse, spam, and inappropriate posts.
This seems to be a way of showing they are improving their services.
They even share data on mistaken abuse reports.
Even if we can’t publish such data, there’s definitely something to learn from this approach.
Thoughts on Limits
Instagram uses limits to prevent fake activities.
While we don’t know how they decide the exact numbers, what’s important is that these policies exist.
Each service will have different numbers, but the key is to set limits at levels that prevent abuse while allowing normal usage.
Before running a service, you might think, “Who would do that?”
But with large-scale services, there will always be users or bots who push the limits.
Instead of thinking, “No one would do this,” you must set policies that ensure, “No one can do this.”
And these policies must be implemented in the service.
Benefits of Limits
The benefits of limits are clear from both operational and service perspectives.
Operational Issues
Using Instagram as an example, imagine if there were no limits.
If a user could follow 1 million or 1 billion accounts,
you’d eventually have to redesign the structure to handle this.
(Follow here means accounts a user follows.)
It doesn’t make sense for someone to follow 1 million accounts.
This isn’t normal behavior, and if it’s allowed,
managing the constant feed updates and stories becomes impossible.
Again, instead of assuming “No one would follow 1 million accounts,”
you need to implement policies that make it impossible.
Setting policies is easy, but fixing issues caused by abuse—such as legal problems or architectural changes—is incredibly difficult.
Service Issues
Service issues mean a drop in quality.
Lower quality reduces a service’s competitiveness, leading to user loss and affecting success.
For example, if Instagram didn’t limit following, abusing users could easily inflate follow counts.
Abusing services that sell fake followers would thrive, and bots would increase spammy posts and ads.
This would lead to lower quality and, eventually, service failure.
Setting Limits
Limits need to be set early.
The longer you wait, the harder it gets to implement them.
Even as developers, we should suggest policies during the service planning stage.
In my current service, abuse doesn’t cause service issues, but operational issues are obvious and increase costs significantly.
Unfortunately, it’s hard for server developers to define such policies,
and adding them later is even harder.
-
Instagram’s post about inauthentic activity explains their stance. ↩
-
Instagram’s follow limit shows accounts that exceeded 7,500 before the limit was set. ↩