シャドーイング練習: System Design: How to Build an API Rate Limiter - 動画で英語スピーキングを学ぶ
レッスンを作成中...
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.
📺 同じチャンネル
✨ おすすめ動画
C13
9 文
Rate Limiter System Design in Under 60 Seconds #techprep #programming #systemdesign
University StudentsWorking Adults
C11
407 文
Why AI Tokens are so Expensive - Computerphile
Business EnglishUniversity StudentsWorking Adults
C11
114 文
Design a File Upload Service Like a Senior Engineer
Business EnglishUniversity StudentsWorking Adults
C12
65 文
What Is REST API? Examples And How To Use It: Crash Course System Design #3
Business EnglishUniversity StudentsWorking Adults
C14
321 文
8 Tech Choices to Lock In Before Agentmaxxing
Business EnglishUniversity StudentsWorking Adults
C11
159 文
Top 5 AI Gateway Use Cases | Solo.io
Business EnglishUniversity StudentsWorking Adults
C11
207 文
How I Made $30,000 Hacking Broken Access Control
Business EnglishUniversity StudentsWorking Adults
C12
82 文
CAP Theorem Simplified
Business EnglishUniversity StudentsWorking Adults
C1105 文
100+ Docker Concepts you Need to Know
American AccentBusiness EnglishUniversity StudentsWorking Adults
C11
284 文
How to Become Your Own ISP
Business EnglishUniversity StudentsWorking Adults
C11
133 文
Data Ingestion Best Practices! How to Ingest Data Efficiently at Enterprise Scale!
Business EnglishUniversity StudentsWorking Adults
C11
177 文
Mini Project - Implementing a Simple Web Identity Federation Application
Business EnglishUniversity StudentsWorking Adults
このレッスンの語彙とスピーキングのポイント
このC1レベルのスピーキングレッスンは、動画「System Design: How to Build an API Rate Limiter」を教材にしています。 繰り返し出てくる語は次のとおりです：Api, user, request, bucket, token。 この動画には、シャドーイング用の文が42文、単語が594語あります。 音声の長さは2:47です。 話す速さは速く、1分あたり約213語です。音のつながりや弱く発音される音が多くなります。 単語の82%は英語の頻出3,000語に含まれます。残りは練習の前に確認しておきましょう。
この動画の重要語彙
動画の中で特に難しい単語12語を、発音と意味つきで紹介します。
| 単語 | 発音 | 意味 |
|---|---|---|
| bucket 名詞 | /ˈbʌkɪt/ | バケツ, 桶 |
| token 名詞 | /ˈtoʊkən/ | トークン |
| server 名詞 | /ˈsɝvɚ/ | サーバー |
| burst 動詞 | /bɜːst/ | 破裂する |
| clock 名詞 | /klɑk/ | 走行距離計 |
| crystal 名詞 | /ˈkɹɪstəl/ | 結晶 |
| belong 動詞 | /bɪˈlɒŋ/ | 所属する, 属する |
| fundamental 形容詞 | /ˌfʌn.dəˈmɛn.təl/ | 基本的な |
| implementation 名詞 | /ˌɪmplɪmənˈteɪʃən/ | 実施, 実用化 |
| millisecond 名詞 | /ˈmɪlɪˌsɛkənd/ | ミリ秒, ミリセカント |
| refill 名詞 | /ˈɹiː.fɪl/ | お代わり, リフィル |
| simplification 名詞 | /ˌsɪm.plɪ.fɪˈkeɪ.ʃən/ | 単純化 |
動画に出てくる句動詞
| 単語 | 意味 |
|---|---|
| slow down 動詞 | 遅らせる |
この動画の文法
話し手がよく使っている文型を、動画の実際の表現とともに紹介します。
| 文型 | 動画での表現 |
|---|---|
| 条件文 if + 節, will/would + 動詞 — 条件とその結果 | If the bucket is empty, we will reject |
| 受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる | 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/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: crystal /ˈkɹɪstəl/, refill /ˈɹiː.fɪl/
- /f/ — 「フ」ではなく、上の歯と下唇で出す: fundamental /ˌfʌn.dəˈmɛn.təl/, refill /ˈɹiː.fɪl/, simplification /ˌsɪm.plɪ.fɪˈkeɪ.ʃən/
- 子音の連続 — 間に母音を入れない: burst /bɜːst/, clock /klɑk/, crystal /ˈkɹɪstəl/, implementation /ˌɪmplɪmənˈteɪʃən/, drain /dɹiːn/
この動画での練習方法
- まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
- まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
- 自分の声を録音して元の音声と比べます。bucket, token, serverなどの単語に特に注意しましょう。
シャドーイングとは？英語上達に効果的な理由
シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。