docs: limits en 작성

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한 <u>api에서는 24시간에 50개의 post만 생성할 수 있도록 제한</u>[^4] 한다.
 
-## facebook 사례
+## Facebook
 
 흥미로운 점은 <u>facebook은 abusing, spam, sexual post 등에 대해 지표</u>[^5]를 관리하고 공개하고 있다.  
 우리 서비스는 더 완성도 높아지고 있다는걸 보여주기 위함인 것 같다.

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.
+
+<u>Instagram's policy on inauthentic activity and spam</u>[^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 <u>following limit</u>[^2], other policies are mostly <u>unofficial</u>[^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 <u>API limits creating posts to 50 per day</u>[^4].
+
+## Facebook
+
+Interestingly, <u>Facebook tracks and shares metrics</u>[^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/).