シャドーイング練習: System Design Was HARD - Until You Knew the Trade-Offs - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

53 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

System design is all about making the right trade-offs, whether building something from scratch or scaling an existing application.

Understanding these core trade-offs will help us make better architectural decisions.

Let's explore some essential system design trade-offs related to data management that every engineer should understand.

When it comes to data storage, SQL and NoSQL databases represent fundamentally different approaches with clear trade-offs.

SQL databases provide strong consistency, structure schemas, and powerful query capabilities.

This structure ensures data integrity, but it creates challenges for horizontal scaling and when modifying schemas.

NoSQL databases invert these priorities.

They often sacrifice some consistency and query capabilities to gain horizontal scalability and and schema flexibility.

With SQL, we're trading scalability for consistency and structure.

With NoSQL, we're trading consistency guarantees and query capability for scalability and flexibility.

This isn't simply about which is better.

It's about understanding the application's specific needs.

Do we need rock solid transactions and complex query capabilities?

SQL might be the answer.

Need to scale massively with evolving data models, NoSQL could be the better choice.

Database design typically starts with normalization,

organizing data into separate tables to minimize redundancy and ensure each piece of information is stored in only one place.

This creates a clean model that maintains data integrity.

But as application scale and performance becomes critical, the cost of joins between normalized tables can become prohibitive.

This is when denormalization enters the picture, deliberately duplicating data across tables to eliminate expensive joins and speed up common queries.

The trade-off is clear.

Normalization optimizes for data integrity and storage efficiency,

while denormalization optimizes for read performance at the cost of increased complexity in write operations and potential inconsistencies.

Most large-scale systems evolve from fully normalized designs towards strategic denormalization only where query performance demands it.

This evolution reflects the shifting priorities as applications mature, from correctness and simplicity to performance and scale.

In distributed systems, the CAP theorem tells us we can't have it all.

Consistency is the assurance of getting the most recent data every single time we make a request.

Availability is about ensuring that the system is always up and running, even if some parts are having problems.

When network partitions occur, we have to choose one over the other.

Banking systems may favor consistency to ensure account balances are always accurate, while social media platforms may favor availability,

so users can always access the service.

This fundamental trade-off shapes how a system behaves under failure conditions and determines which guarantees we can provide to users.

But consistency itself isn't binary, it's a spectrum.

Strong consistency is when data updates are immediately reflected across all nodes in the system.

It requires synchronization, which can affect performance.

Eventual consistency is when data updates a delay before being available across nodes.

This approach is faster and more scalable, but users might temporarily see stale data.

The tradeoff is between speed and scale versus the immediacy and accuracy of updates.

The business requirements dictate where on this spectrum a system should operate.

The way we process data presents another fundamental tradeoff.

Batch processing accumulates data and processes it at scheduled intervals.

This offers computational efficiency and simpler error handling, but introduces significant latency.

Users wait hours for insights.

Stream processing handles data in real-time as it arrives, providing immediate results and enabling instant reactions to events.

However, this introduces complexity because out-of-order data arrivals and variable latency can compromise correctness,

requiring sophisticated state management and processing guarantees.

The core trade-off is between efficiency and simplicity versus immediacy and responsiveness.

Many modern systems end up with hybrid architectures, using streams for time-sensitive processing and batch for comprehensive analysis.

Understanding these trade-offs is essential for designing systems that meet our specific requirements.

There are no universally correct choices, only trade-offs that align better with a particular use case.

If you like our videos, you might like our system design newsletter as well.

It covers topics and trends in large-scale system design, trusted by 1 million readers.

Subscribe at blog.buybygo.com.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

FOR YOU

このレッスンの語彙とスピーキングのポイント

このC1レベルのスピーキングレッスンは、動画「System Design Was HARD - Until You Knew the Trade-Offs」を教材にしています。繰り返し出てくる語は次のとおりです：consistency, trade, scale, design, query。この動画には、シャドーイング用の文が53文、単語が685語あります。音声の長さは5:06です。話す速さは1分あたり約134語で安定しており、シャドーイングしやすいペースです。英語の頻出3,000語に含まれる単語は70%だけなので、語彙は難しめです。

この動画の重要語彙

動画の中で特に難しい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
query 名詞	/ˈkwɪɹ.i/	質問
capability 名詞	/ˌkeɪ.pəˈbɪl.ɪ.ti/	能力
denormalization 名詞		非正規化
scalability 名詞	/ˌskeɪ.ləˈbɪl.ɪ.ti/	伸縮性, 拡張性
schema 名詞	/ˈskiːmə/	スキーマ
latency 名詞	/ˈleɪ.tən.si/	潜在, 秘匿
normalization 名詞	/ˌnɔɹ.mə.ləˈzeɪ.ʃən/	正常化, 正規化
node 名詞	/noʊd/	結節
horizontal 形容詞	/ˌhoɹəˈzɑn.təl/	水平な, 横の
batch 名詞	/bæt͡ʃ/	ひと焼き分
flexibility 名詞	/ˌflɛksɪˈbɪlɪti/	柔軟性, 可撓性
complexity 名詞	/kəmˈplɛk.sɪ.ti/	複雑さ
accumulate 動詞	/əˈkjuːmjʊˌleɪt/	積む
inconsistency 名詞	/ˌɪnkənˈsɪstənsi/	ねじれ, 不一致
invert 動詞	/ɪnˈvɜɹt/	反転

動画に出てくる句動詞

単語	発音	意味
speed up 動詞	/spiːdˈʌp/	スピードを出す

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	is stored · are immediately reflected
関係詞節 who / which + 節 — 人や物について情報を加える	about which is · synchronization, which can

注意したい発音

話し手はisn't, we're, can'tなど、短縮形や弱形を5回使っています。聞こえたとおりの短い形で発音しましょう。

「sh」と「zh」の音: normalization /ˌnɔɹ.mə.ləˈzeɪ.ʃən/, computational /ˌkɑmpjʊˈteɪʃənəl/, partition /pɑɹˈtɪ.ʃən/, assurance /əˈʃʊɹəns/
長い単語（アクセントの位置に注意）: consistency /kənˈsɪs.tən.si/, capability /ˌkeɪ.pəˈbɪl.ɪ.ti/, scalability /ˌskeɪ.ləˈbɪl.ɪ.ti/, immediacy /ɪˈmiːdi.əsi/, normalization /ˌnɔɹ.mə.ləˈzeɪ.ʃən/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: normalization /ˌnɔɹ.mə.ləˈzeɪ.ʃən/, horizontal /ˌhoɹəˈzɑn.təl/, architectural /ˌɑɹkɪˈtɛkt͡ʃəɹəl/, deliberately /dɪˈlɪb.(ə.)ɹət.li/, temporarily /ˌtɛmpəˈɹɛɹəli/
/v/ — /b/ にならないように、上の歯を下唇に当てる: evolve /ɪˈvɑlv/, invert /ɪnˈvɜɹt/, prohibitive /pɹəˈhɪbɪtɪv/, responsiveness /ɹɪˈspɑn.sɪv.nɪs/, massively /ˈmæs.ɪv.li/
/f/ — 「フ」ではなく、上の歯と下唇で出す: flexibility /ˌflɛksɪˈbɪlɪti/, modify /ˈmɑ.dɪˌfaɪ/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
通常の速度で一文ずつシャドーイングし、話し手のリズムに合うまで繰り返します。
自分の声を録音して元の音声と比べます。query, capability, denormalizationなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: System Design Was HARD - Until You Knew the Trade-Offs - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

Proxy vs Reverse Proxy (Real-world Examples)

Cache Systems Every Developer Should Know

Top 5 Redis Use Cases

Everything You Need to Know About DNS: Crash Course System Design #4

CAP Theorem Simplified

What Is REST API? Examples And How To Use It: Crash Course System Design #3

8 Most Important System Design Concepts You Should Know

The Secret Sauce Behind NoSQL: LSM Tree

System Design: Why is Kafka fast?

What Are Microservices Really All About? (And When Not To Use It)

How Does a URL Shortener Work?

System Design: Why is Kafka Popular?

What is API Gateway?

10+ Key Memory & Storage Systems: Crash Course System Design #5

Kubernetes Explained in 6 Minutes | k8s Architecture

What Is Redis Really About? Why Is It So Popular?

How Git Works: Explained in 4 Minutes

おすすめ動画

Microservices with Databases can be challenging...

The Paradox of Choice • Level 4 [B2] • ESL Listening

SDLC Vs STLC: Software Development Life Cycle and Software Testing Life Cycle

Database Sharding! Designing Data-Intensive Applications chapter 6

what is a database index?

A 4-Step System to Process Information with Extreme Clarity

Design a File Upload Service Like a Senior Engineer

Armchair Architects: Resiliency in the Cloud – Core Patterns

Every Networking Concept Explained In 20 Minutes

If you’re an aspiring product designer, watch this (roadmap included)