Shadowing Practice: System Design: How to Build an API Rate Limiter - Learn English Speaking with Video
בחר מצב תרגול
כל מצב פותח חדר תרגול במסך מלא.
42 משפטים
אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.
1
Let's design an API rate limiter for an application that takes thousands of requests per second.
2
User journey is simple.
3
User can make API calls to your server to do something.
4
Each user is allowed to make 100 API calls per minute.
5
If a user makes more than 100 calls per minute, then your server will not process those API calls.
6
Most engineers approach this problem with a counter.
7
For each user, you store user ID, count of API calls, and current minute.
8
Every time a request is made by user, you increase this count, and you will reject the requests once it passes 100 requests.
9
This implementation is good enough for internal API calls, but let's take two specific examples why this solution is not good.
10
Let's say user Alan is a burst user, and makes 100 API calls in first two seconds.
11
Then he will get rejected for the next 58 seconds.
12
Alan will be able to make calls when next minute starts.
13
And our second user, John, sends 100 API requests, but these requests are sent at the last second of the current minute.
14
The next second clock will reset to new minute, and John can send another 100 requests.
15
Basically, John sent 200 requests in 2 seconds, because according to Counter, these 100 requests belong to different minutes.
16
Basically, users will experience different behavior of APIs based on when they make the API call.
17
There is a fundamental issue with the approach we just discussed.
18
The Counter is watching the clock instead of watching the user.
19
Let's see a better approach.
20
So, we will give every user a bucket that holds 100 tokens.
21
Every API request from user takes one token out, and we will keep filling the bucket at a rate of 100 tokens per minute, which is approximately 1.67 tokens per second.
22
For simplification, let's assume we will fill two tokens per second.
23
If user doesn't make any API call, the bucket will remain at 100, and we don't need to fill.
24
If the bucket is empty, we will reject the request.
25
This token bucket approach is what Stripe, GitHub, and most API gateways actually use for tracking API calls.
26
Now let's take a look at Alan and John's requests again, and see how this bucket system will work.
27
Alan drains all 100 tokens in 2 seconds.
28
Then Alan has to slow down.
29
Bucket fills about 2 tokens per second.
30
That's why he can now make 2 calls per second.
31
John, who is making 100 API calls at the end of the minute, will also need to wait for Bucket to fill, because once he makes 100 requests in a second, Bucket will get empty.
32
So he can also make about 2 per second, as Bucket fills with time.
33
Next question is, how do we store these buckets?
34
We just need to store the token count, and the time of the last refill, so that you can add tokens per second.
35
But what if your app works at large scale, and you have 20 different servers accepting API calls.
36
Two requests for the same user can land on two servers in the same millisecond.
37
Therefore, you keep the bucket outside the servers, in one common shared storage.
38
This storage needs to be fast, and that's why we usually use Redis.
39
When any of these 20 servers processes any API call, we change the count at this common Redis.
40
To make this crystal clear in your mind, you need to remember that request limit is not just one number.
41
It's two numbers.
42
First, how much a user can burst in one go, and second, how fast they can go after the burst.
הורד אפליקציה
כל מה שאתה צריך כדי לדבר בשטף
הגיית AIציון לכל משפט
תרגול IPAשלוט בכל צליל
אוצר מיליםבנה את מאגר המילים שלך
משחק אוצר מיליםלמד תוך כדי משחק
אותו ערוץ
FOR YOU
המלץ על סרטון
C13
9 משפטים
Rate Limiter System Design in Under 60 Seconds #techprep #programming #systemdesign
Daily ConversationUniversity StudentsWorking Adults
C1327 משפטים
11 Marketing Strategies that Almost NEVER Fail (in any niche)
Business EnglishUniversity StudentsWorking Adults
C11
180 משפטים
Your API Can’t Handle Real-World Integrations
Business EnglishUniversity StudentsWorking Adults
C13
29 משפטים
How Bitcoin Works in 5 Minutes (Technical)
Business EnglishUniversity StudentsWorking Adults
C14
164 משפטים
System Design Mock Interview: Design Facebook Messenger
Business EnglishUniversity StudentsWorking Adults
C22
129 משפטים
2.2k
Business EnglishUniversity StudentsWorking Adults
C14
76 משפטים
The Limitless AI Lie. The Bubble Is Slowly BURSTING.
Business EnglishDaily ConversationUniversity Students
C12
130 משפטים
Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond
Business EnglishUniversity StudentsWorking Adults
C130
26 משפטים
Docker in 100 Seconds
American AccentBusiness EnglishUniversity StudentsWorking Adults
C14
41 משפטים
What is API Gateway?
Business EnglishUniversity StudentsWorking Adults
C1101 משפטים
What is a Run@Rate? Meaning of a Run@Rate!
Business EnglishUniversity StudentsWorking Adults
אוצר מילים והערות הגייה לשיעור הזה
שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “System Design: How to Build an API Rate Limiter”. המילים שחוזרות הכי הרבה: Api, user, request, bucket, token. בסרטון הזה יש 42 משפטים ו-594 מילים לתרגול Shadowing. הדיבור נמשך 2:47. הדובר מדבר מהר, כ-213 מילים בדקה, אז צפו לצלילים מחוברים ומקוצרים. 82% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.
אוצר מילים מרכזי בסרטון הזה
8 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:
| מילה | הגייה | משמעות |
|---|---|---|
| bucket שם עצם | /ˈbʌkɪt/ | דְּלִי |
| token שם עצם | /ˈtoʊkən/ | אֲסִימוֹן, זִ׳יטוֹן |
| server שם עצם | /ˈsɝvɚ/ | שָׁרָת |
| burst פועל | /bɜːst/ | התפוצץ |
| crystal שם עצם | /ˈkɹɪstəl/ | גָּבִישׁ |
| implementation שם עצם | /ˌɪmplɪmənˈteɪʃən/ | מִימוּשׁ, בִּצוּעַ |
| drain שם עצם | /dɹiːn/ | נִקּוּז, אגן נקוז |
| reset פועל | /ɹiːˈsɛt/ | אפס |
דקדוק בסרטון הזה
המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:
| מבנה | בסרטון |
|---|---|
| משפטי תנאי (Conditional sentences) if + clause, will/would + verb — תנאי ותוצאה שלו | If the bucket is empty, we will reject |
| סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה | is allowed · is made · are sent |
הגייה ששווה לשים לב אליה
- הצלילים של “sh” ו-“zh”: implementation /ˌɪmplɪmənˈteɪʃən/, simplification /ˌsɪm.plɪ.fɪˈkeɪ.ʃən/
- מילים ארוכות — שימו לב להטעמה: fundamental /ˌfʌn.dəˈmɛn.təl/, implementation /ˌɪmplɪmənˈteɪʃən/, millisecond /ˈmɪlɪˌsɛkənd/, simplification /ˌsɪm.plɪ.fɪˈkeɪ.ʃən/
צלילים שדוברי עברית מתקשים בהם:
- /r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: crystal /ˈkɹɪstəl/, drain /dɹiːn/, reset /ɹiːˈsɛt/, refill /ˈɹiː.fɪl/
איך לתרגל עם הסרטון הזה
- הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
- התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
- הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו bucket, token, server.
מהי טכניקת השאדואינג?
שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.