쉐도잉 연습: 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입니다. 화자는 분당 약 134단어의 일정한 속도로 말해서 섀도잉하기에 편한 속도입니다. 영어에서 가장 많이 쓰이는 3,000단어에 속하는 단어가 70%뿐이라 어휘가 어려운 편입니다.

이 영상의 핵심 어휘

영상에서 가장 어려운 단어 15개를 발음, 뜻과 함께 정리했습니다.

단어	발음	뜻
query 명사	/ˈkwɪɹ.i/	질문
scalability 명사	/ˌskeɪ.ləˈbɪl.ɪ.ti/	신축성
schema 명사	/ˈskiːmə/	스키마
node 명사	/noʊd/	결절
horizontal 형용사	/ˌhoɹəˈzɑn.təl/	가로의, 수평의
flexibility 명사	/ˌflɛksɪˈbɪlɪti/	유연성
accumulate 동사	/əˈkjuːmjʊˌleɪt/	모으다, 축적하다
redundancy 명사	/ɹɪˈdʌndən(t)si/	중복성
synchronization 명사		싱크로
duplicate 동사	/ˈd(j)uː.plɪˌkeɪt/	복사하다
theorem 명사	/ˈθiərəm/	정리
newsletter 명사	/ˈn(j)uzˌlɛtɚ/	뉴스레터
interval 명사	/ˈɪntɚvəl/	간격
modify 동사	/ˈmɑ.dɪˌfaɪ/	수정하다
minimize 동사	/ˈmɪn.ɪˌmaɪz/	최소화(最小化)하다

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
수동태 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/

한국어 화자가 어려워하는 소리:

/f/ — ㅍ(/p/)으로 바꾸지 말고 윗니를 아랫입술에 대기: flexibility /ˌflɛksɪˈbɪlɪti/, modify /ˈmɑ.dɪˌfaɪ/
/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/
/z/ — ㅈ이 아니라 성대를 울리는 /s/: normalization /ˌnɔɹ.mə.ləˈzeɪ.ʃən/, normalize /ˈnɔː.mə.laɪz/, optimize /ˈɑptɪmaɪz/, horizontal /ˌhoɹəˈzɑn.təl/, newsletter /ˈn(j)uzˌlɛtɚ/

이 영상으로 연습하는 방법

먼저 말하지 않고 영상을 끝까지 듣고 모르는 단어를 적어 둡니다.
보통 속도로 한 문장씩 섀도잉하고, 화자의 리듬과 맞을 때까지 반복합니다.
자신의 목소리를 녹음해 원본과 비교하고, query, scalability, schema 같은 단어에 특히 주의합니다.

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(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

System Design: Why is Kafka fast?

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

System Design: Why is Kafka Popular?

The Secret Sauce Behind NoSQL: LSM Tree

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 Does a URL Shortener Work?

How Git Works: Explained in 4 Minutes

추천 영상

Microservices with Databases can be challenging...

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

How to Avoid Doing UX Theatre

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