시스템 설계 기술 면접 영어 가이드: Architecture Discussion·Trade-off Analysis·Scaling 표현과 실전 대화

[면접 시작 - 요구사항 확인]

"Before I dive into the design, let me clarify a few requirements."
(설계에 들어가기 전에, 몇 가지 요구사항을 확인하겠습니다.)

"What's the expected scale of this system? Are we talking about
thousands or millions of users?"
(이 시스템의 예상 규모는 어떻게 되나요? 수천 명인지 수백만 명인지?)

"Should we focus on read-heavy or write-heavy workloads?"
(읽기 중심인지 쓰기 중심인지 초점을 맞춰야 할까요?)

"What are the most critical non-functional requirements?
Latency, availability, or consistency?"
(가장 중요한 비기능 요구사항은 무엇인가요?
지연시간인지, 가용성인지, 일관성인지?)

[범위 설정]

"Given the time constraint, I'd like to focus on the core
functionality first and then discuss extensions if time permits."
(시간 제약을 고려하여, 핵심 기능에 먼저 집중하고 시간이 허락하면
확장 기능을 논의하겠습니다.)

"Let me scope this down. For the initial design, I'll focus on
the messaging system and defer the notification system."
(범위를 좁히겠습니다. 초기 설계에서는 메시징 시스템에 집중하고
알림 시스템은 나중에 다루겠습니다.)

"Are there any specific features you'd like me to prioritize?"
(우선적으로 다뤘으면 하는 특정 기능이 있나요?)

[수치 확인]

"What's the expected QPS (queries per second) for this service?"
(이 서비스의 예상 QPS는 얼마인가요?)

"How much data are we expecting to store? What's the retention period?"
(저장해야 할 데이터 양은 얼마나 되나요? 보관 기간은요?)

"What's the acceptable latency for the end user?
Sub-100 milliseconds or is higher latency acceptable?"
(최종 사용자에게 허용 가능한 지연시간은 얼마인가요?
100밀리초 이하인지, 더 높은 지연시간도 괜찮은지?)

[아키텍처 개요]

"Let me start with a high-level architecture overview."
(상위 레벨의 아키텍처 개요부터 시작하겠습니다.)

"At a high level, this system consists of three main components:
an API gateway, a processing layer, and a data storage layer."
(상위 수준에서, 이 시스템은 세 가지 주요 컴포넌트로 구성됩니다:
API 게이트웨이, 처리 레이어, 데이터 저장 레이어입니다.)

"The API gateway routes all incoming requests and applies
rate limiting and authentication."
(API 게이트웨이는 모든 수신 요청을 라우팅하고
속도 제한과 인증을 적용합니다.)

[컴포넌트 상호작용]

"When a user sends a message, the request first hits
the load balancer, which distributes it to one of our
application servers."
(사용자가 메시지를 보내면, 요청은 먼저 로드 밸런서에 도달하고,
로드 밸런서가 이를 애플리케이션 서버 중 하나로 분배합니다.)

"The application server validates the request, writes to
the message queue for asynchronous processing, and returns
a confirmation to the client."
(애플리케이션 서버가 요청을 검증하고, 비동기 처리를 위해
메시지 큐에 쓴 다음, 클라이언트에게 확인 응답을 반환합니다.)

"This microservice is stateless, which makes scaling
much easier because we can simply add more instances
behind the load balancer."
(이 마이크로서비스는 상태를 갖지 않아서(stateless), 로드 밸런서 뒤에
인스턴스를 추가하기만 하면 되므로 확장이 훨씬 쉽습니다.)

[데이터 흐름]

"Let me walk you through the data flow for a typical request."
(일반적인 요청에 대한 데이터 흐름을 설명하겠습니다.)

"The data flows from the client through the CDN for static
assets, then hits our API servers for dynamic content."
(데이터는 클라이언트에서 정적 자산을 위한 CDN을 거치고,
동적 컨텐츠를 위해 API 서버에 도달합니다.)

"We use an event-driven architecture here, where services
communicate through a message broker rather than direct
API calls."
(여기서는 이벤트 기반 아키텍처를 사용합니다. 서비스들이
직접 API 호출 대신 메시지 브로커를 통해 소통합니다.)

[트레이드오프 설명]

"The trade-off here is between consistency and availability.
Given that this is a social media feed, I'd prioritize
availability over strict consistency."
(여기서의 트레이드오프는 일관성과 가용성 사이입니다.
소셜 미디어 피드이므로, 엄격한 일관성보다
가용성을 우선시하겠습니다.)

"On one hand, using a relational database gives us strong
consistency and ACID transactions. On the other hand,
a NoSQL database would give us better horizontal scalability."
(한편으로, 관계형 데이터베이스는 강한 일관성과 ACID 트랜잭션을
제공합니다. 반면, NoSQL 데이터베이스는 더 나은 수평 확장성을
제공합니다.)

"There's a tension between latency and data freshness.
Caching improves latency but introduces the risk of
serving stale data."
(지연시간과 데이터 최신성 사이에 긴장이 있습니다.
캐싱은 지연시간을 개선하지만, 오래된 데이터를 제공할
위험이 있습니다.)

[선택 근거]

"I'm going with eventual consistency here because, for this
use case, users can tolerate a few seconds of delay before
seeing the latest data."
(이 경우 최종 일관성을 선택합니다. 이 사용 사례에서는
사용자가 최신 데이터를 보기까지 몇 초의 지연을 허용할 수 있기 때문입니다.)

"I'd choose a message queue over direct synchronous calls
because it decouples the services and improves fault tolerance.
If the downstream service goes down, messages are preserved
in the queue."
(직접 동기 호출 대신 메시지 큐를 선택하겠습니다.
서비스를 분리하고 장애 내성을 향상시키기 때문입니다.
하위 서비스가 다운되더라도 메시지는 큐에 보존됩니다.)

"The downside of this approach is increased complexity in
managing distributed transactions, but I believe the benefits
of independent deployability outweigh this cost."
(이 접근법의 단점은 분산 트랜잭션 관리의 복잡성 증가이지만,
독립적 배포 가능성의 이점이 이 비용보다 크다고 생각합니다.)

[대안 비교]

"I considered two approaches: a push model and a pull model.
The push model has lower latency for notifications, but
the pull model is simpler to implement and scales better
for users who follow many accounts."
(두 가지 접근법을 고려했습니다: 푸시 모델과 풀 모델입니다.
푸시 모델은 알림 지연시간이 낮지만, 풀 모델은 구현이 더 간단하고
많은 계정을 팔로우하는 사용자에게 더 잘 확장됩니다.)

"Another option would be to use a hybrid approach,
where we use push for active users and pull for
less active users."
(또 다른 옵션은 하이브리드 접근법을 사용하는 것입니다.
활성 사용자에게는 푸시를, 비활성 사용자에게는 풀을 사용합니다.)

[스케일링 전략]

"We could horizontally scale this service by adding more
instances behind the load balancer. Since the service is
stateless, horizontal scaling is straightforward."
(이 서비스는 로드 밸런서 뒤에 인스턴스를 추가하여
수평 확장할 수 있습니다. 서비스가 stateless이므로
수평 확장이 간단합니다.)

"For the database layer, vertical scaling might be
sufficient initially, but as we grow beyond a certain
threshold, we'll need to implement sharding."
(데이터베이스 레이어의 경우, 초기에는 수직 확장으로 충분할 수 있지만,
특정 임계치를 넘어 성장하면 샤딩을 구현해야 합니다.)

"Horizontal scaling provides better fault tolerance
since there's no single point of failure, but it
introduces complexity in data consistency."
(수평 확장은 단일 장애점이 없어 더 나은 장애 내성을 제공하지만,
데이터 일관성에 복잡성을 도입합니다.)

[병목 식별]

"The database is likely to become a bottleneck as the
number of concurrent users increases. To address this,
we can introduce read replicas and a caching layer."
(동시 사용자 수가 증가하면 데이터베이스가 병목 지점이 될 가능성이
높습니다. 이를 해결하기 위해 읽기 복제본과 캐싱 레이어를 도입할 수 있습니다.)

"I'd identify the potential bottlenecks as follows:
first, the write path to the database; second, the
computation-heavy recommendation engine; and third,
the network bandwidth for media delivery."
(잠재적 병목 지점을 다음과 같이 식별하겠습니다:
첫째, 데이터베이스에 대한 쓰기 경로; 둘째, 계산 집약적인
추천 엔진; 셋째, 미디어 전달을 위한 네트워크 대역폭입니다.)

"Caching the most common queries reduced average latency
by 40 percent in similar systems I've worked with."
(가장 빈번한 쿼리를 캐싱하면 제가 경험한 유사 시스템에서
평균 지연시간이 40퍼센트 감소했습니다.)

[성능 최적화]

"We can use a CDN to serve static content closer to
the user, reducing latency significantly."
(CDN을 사용하여 정적 콘텐츠를 사용자에게 더 가깝게 제공하면
지연시간을 크게 줄일 수 있습니다.)

"To handle traffic spikes, I'd implement auto-scaling
policies based on CPU utilization and request count."
(트래픽 급증에 대응하기 위해, CPU 사용률과 요청 수에 기반한
자동 확장 정책을 구현하겠습니다.)

"We can implement circuit breakers to prevent cascading
failures when a downstream service is unresponsive."
(하위 서비스가 응답하지 않을 때 연쇄 장애를 방지하기 위해
서킷 브레이커를 구현할 수 있습니다.)

[데이터베이스 선택]

"For the user profile data, I'd use a relational database
like PostgreSQL because we need strong consistency,
complex queries with joins, and ACID transactions."
(사용자 프로필 데이터에는 PostgreSQL 같은 관계형 데이터베이스를
사용하겠습니다. 강한 일관성, 조인이 포함된 복잡한 쿼리,
ACID 트랜잭션이 필요하기 때문입니다.)

"For the activity feed, I'd choose a NoSQL database like
Cassandra because it's optimized for write-heavy workloads
and provides excellent horizontal scalability."
(활동 피드에는 Cassandra 같은 NoSQL 데이터베이스를 선택하겠습니다.
쓰기 중심의 워크로드에 최적화되어 있고 뛰어난 수평 확장성을
제공하기 때문입니다.)

"For the caching layer, Redis would be a good fit because
it supports various data structures, provides sub-millisecond
latency, and supports pub/sub for real-time features."
(캐싱 레이어에는 Redis가 적합합니다. 다양한 데이터 구조를 지원하고,
밀리초 이하의 지연시간을 제공하며, 실시간 기능을 위한
pub/sub을 지원하기 때문입니다.)

[스키마 설계]

"For this table, I'd denormalize the data to avoid
expensive join operations at read time."
(이 테이블에서는 읽기 시 비용이 많이 드는 조인 연산을
피하기 위해 데이터를 비정규화하겠습니다.)

"I'd add an index on the user_id and created_at columns
to optimize the query pattern for fetching recent posts
by a specific user."
(특정 사용자의 최근 게시물을 가져오는 쿼리 패턴을 최적화하기 위해
user_id와 created_at 컬럼에 인덱스를 추가하겠습니다.)

"The partition key would be the user_id, which ensures
even distribution of data across shards and efficient
lookups for user-specific data."
(파티션 키는 user_id가 되며, 이는 샤드 간 데이터의
균등한 분배와 사용자별 데이터의 효율적인 조회를 보장합니다.)

[면접관] "Design a URL shortening service like bit.ly."

[지원자] "Sure, I'd love to work through this.
Before I start, let me clarify a few requirements.

First, what's the expected scale?
How many URLs are we shortening per day?"

[면접관] "Let's say 100 million new URLs per day,
and a 10:1 read-to-write ratio."

[지원자] "Got it. So that's roughly 100 million writes per day
and about 1 billion reads per day.

Let me do a quick back-of-the-envelope calculation.
That's about 1,200 writes per second and 12,000 reads
per second on average, with potential peaks of maybe
3 to 5 times that.

For the high-level design, I'd propose the following
components:

1. An API gateway for rate limiting and authentication
2. A URL shortening service that generates unique short codes
3. A redirection service that handles the lookups
4. A database to store the URL mappings
5. A caching layer for frequently accessed URLs

For generating the short URL, I have a few options.
I could use a hash function like MD5 or SHA-256 and
take the first 7 characters, or I could use a
base-62 encoding with an auto-incrementing counter.

I'd go with the base-62 approach using a distributed
ID generator because it guarantees uniqueness without
collision handling, which simplifies the system.

The trade-off is that base-62 with a counter is
slightly less random than hashing, which means
sequential URLs are somewhat predictable. But for
a URL shortener, this isn't a security concern."

[면접관] "How would you handle the database layer?"

[지원자] "For the database, I'd use a NoSQL store like
DynamoDB or Cassandra. Here's my reasoning:

The data model is simple - it's essentially a
key-value lookup from short URL to long URL.
We don't need complex joins or transactions.
The access pattern is primarily point reads by key.
NoSQL databases excel at horizontal scaling for
this type of workload.

To improve read performance, I'd add a Redis cache
in front of the database. Given the 10:1 read-to-write
ratio, caching would significantly reduce database load.

For the cache eviction policy, I'd use LRU
(Least Recently Used) since popular URLs tend to
be accessed repeatedly within short time windows."

[면접관] "What about availability and reliability?"

[지원자] "Great question. For high availability, I'd
implement the following:

First, the application servers are stateless,
so we can run multiple instances behind a load
balancer. If one instance fails, traffic is
automatically rerouted.

Second, for the database, I'd use multi-region
replication to handle regional failures.

Third, the cache layer would use a cluster setup
with automatic failover.

The main trade-off for multi-region replication is
between consistency and latency. I'd opt for
eventual consistency with a replication lag of
a few seconds, which is acceptable for a URL
shortener since a newly created URL doesn't need
to be globally available instantly."

[BAD]
"Okay, so I'll use a microservices architecture
with Kafka and Redis and..."

[GOOD]
"Before I jump into the solution, let me make sure
I understand the requirements correctly.
What's the expected scale, and what are the most
critical quality attributes for this system?"

[BAD]
"I'd use Kafka here."

[GOOD]
"I'd use a message queue here - something like Kafka
or RabbitMQ. The key reason is that we need to decouple
the write path from the processing pipeline to handle
traffic spikes gracefully."

[BAD]
"I'd use caching to improve performance."

[GOOD]
"I'd introduce a caching layer to improve read latency.
The trade-off is that we might serve stale data, but
for this use case, a TTL of 5 minutes is acceptable
because users can tolerate slightly outdated information."

[BAD]
"This system should handle a lot of traffic."

[GOOD]
"Based on our earlier estimates of 100 million daily
active users, we need to handle approximately 12,000
requests per second at peak, assuming a 3x peak-to-average
ratio."

[BAD - 한국어 직역]
"If many users come at the same time, the server becomes
not good."

[GOOD - 자연스러운 영어]
"Under high concurrency, the server may become overwhelmed,
leading to increased latency and potential timeouts."