diff --git a/docs/14.service/2022-06-19-limits.md b/docs/14.service/2022-06-19-limits.md index 5603ca46..36d43834 100644 --- a/docs/14.service/2022-06-19-limits.md +++ b/docs/14.service/2022-06-19-limits.md @@ -3,6 +3,7 @@ layout: post title: Instagram, Facebook에서 배우는 유저 제한 정책, 서비스 정책의 중요성 sidebar_label: User Limits parent: Service +lang: ko permalink: /docs/service/user-limits sitemap: lastmod: 2024-03-20 @@ -13,8 +14,7 @@ sitemap: 최근 회사에서 abusing user 이슈를 겪었다. -내가 관리하는 서비스 중 일정을 동기화 하는 서비스가 있는데, -batch 작업 중 사용자 한 명이 100만 개 이상의 일정을 가지고 있는 케이스를 발견했다. +내가 관리하는 서비스 중 일정을 동기화 하는 서비스가 있는데, batch 작업 중 사용자 한 명이 100만 개 이상의 일정을 가지고 있는 케이스를 발견했다. 반복 일정(매주 화요일 10시 회의) 같은건 하나의 일정으로 치는 것을 감안했을 때 일반 사용자가 만들어낸 일정이라고 볼 수 없었다. - 심지어 10분 만에 1000개의 일정을 만들기도 했다. @@ -25,7 +25,7 @@ batch 작업 중 사용자 한 명이 100만 개 이상의 일정을 가지고 최근 인스타그램과 페이스북의 api를 보면서 우리 문제를 돌아보게 되었다. -## 인스타그램 사례 +## 인스타그램 limits (제약 사항)에 대해 잘 적용된 서비스는 인스타그램만한 예시가 없을 것 같다. 이해하기도 쉽고. @@ -58,7 +58,7 @@ limits (제약 사항)에 대해 잘 적용된 서비스는 인스타그램만 developer에게 open한 api에서는 24시간에 50개의 post만 생성할 수 있도록 제한[^4] 한다. -## facebook 사례 +## Facebook 흥미로운 점은 facebook은 abusing, spam, sexual post 등에 대해 지표[^5]를 관리하고 공개하고 있다. 우리 서비스는 더 완성도 높아지고 있다는걸 보여주기 위함인 것 같다. diff --git a/docs/14.service/2022-06-19-limits_EN.md b/docs/14.service/2022-06-19-limits_EN.md new file mode 100644 index 00000000..d55caa0d --- /dev/null +++ b/docs/14.service/2022-06-19-limits_EN.md @@ -0,0 +1,136 @@ +--- +layout: post +title: Instagram, Facebook에서 배우는 유저 제한 정책, 서비스 정책의 중요성 +sidebar_label: User Limits +parent: Service +lang: en +permalink: /docs/service/user-limits +sitemap: + lastmod: 2024-03-20 +--- + +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. + + +## Instagram + +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 spam[^1] 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 limit[^2], other policies are mostly unofficial[^3]. 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 day[^4]. + +## Facebook + +Interestingly, Facebook tracks and shares metrics[^5] 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. + +--- + +[^1]: [Instagram's post about inauthentic activity](https://business.instagram.com/blog/reducing-inauthentic-activity-on-instagram) explains their stance. +[^2]: [Instagram's follow limit](https://help.instagram.com/408167069251249?locale=ko_KR) shows accounts that exceeded 7,500 before the limit was set. +[^3]: [Unofficial Instagram policy sources](https://goinstagram.com/instagram-follow-unfollow-limit). +[^4]: [Instagram API limits](https://developers.facebook.com/docs/instagram-api/guides/content-publishing). +[^5]: [Facebook's spam-related metrics](https://transparency.fb.com/data/community-standards-enforcement/spam/facebook/).