결제 시스템

결제 (payment) system: 금전적 가치의 이전을 통해 금융 거래를 정산하는 데 사용되는 모든 system

1단계: 문제 이해 및 설계 범위 확정

• 기능 요구사항
  • 대금 수신 (pay-in) 흐름: 결제 system이 판매자를 대신하여 고객으로부터 대금 수령
  • 대금 정산 (pay-out) 흐름: 결제 system이 전 세계의 판매자에게 제품 판매 대금 송금
• 비기능 요구사항
  • 신뢰성 및 내결함성: 결제 실패는 신중하게 처리
  • 내부 service (결제 system, 회계 system)와 외부 service (결제 servcice 제공업체) 간의 조정 process: System 간의 결제 정보가 일치하는지 비동기적으로 확인
• 개략적인 규모 추정
  • 하루에 100만 건의 transaction 처리
  • $1,000,000/10^5=10TPS$
  • 10TPS는 일반적 database로 문제 없이 처리 가능하기 때문에 처리 대역폭 대신 결제 transaction의 정확한 처리에 초점

실시간 게임 순위표

순위표: Leaderboard of an online mobile game

1단계: 문제 이해 및 설계 범위 확정

• 기능 요구사항
  • 순위표에 상위 10명의 player 표시
  • 특정 사용자의 순위 표시
  • 어떤 사용자보다 4순위 위와 아래에 있는 사용자 표시
• 비기능 요구사항
  • 점수 update는 실시간으로 순위표에 반영
  • 일반적인 확장성, 가용성 및 안정성 요구사항
• 개략적 규모 추정
  • Game을 하는 사용자가 24시간 동안 고르게 분포 가정
    • DAU가 5,000,000명인 경우 초당 평균 50명 game play
    • $\because\frac{5,000,000DAU}{10^5sec}\simeq50$
  • 하지만 그렇게 균등한 경우는 존재하지 않고 북미 지역 기준 저녁 시간이 peak 시간대일 가능성이 높음
    • 최대 부하는 평균의 5배라 가정
    • $\therefore$ 초당 최대 250명의 사용자를 감당할 수 있어야 함
  • 사용자 점수 획득 QPS
    • 한 사용자가 하루 평균 10개 game play 가정
    • $\therefore 50\times10\times5=2,500$
  • 상위 10명 순위표 가져오기 QPS
    • 각 사용자가 하루에 한 번 game을 열고 상위 10명 순위표는 사용자가 처음 게임을 열 때만 표시한다고 가정
    • 초당 평균 50명이 game play하기 때문에 QPS는 약 50

S3와 유사한 객체 저장소

Amazon S3 (Simple Storage Service): RESTful API 기반 interface로 이용 가능한 객체 저장소

• 2006년 6월: S3 service 시작
• 2010년: Versioning 기능, bucket policy, multipart upload 기능 제공
• 2011년: Server 측 암호화, 여러 객체 삭제, 객체 만료 등 지원
• 2013년: S3에 약 2조 개의 객체 저장
• 2014년 ~ 2015년: Life cycle policy, event notification, cross-region replication 등 기능 도입
• 2021년: S3에 약 100조 개 이상의 객체 저장

Conditional Statement

TypeScript는 JavaScript와 동일한 조건문 구문을 사용하지만, type checking을 통해 code의 안전성을 높인다.

if-else Statement

기본적인 조건 분기 구문으로, 조건에 따라 다른 code block을 실행한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// 기본 if-else 구문
const age = 25;

if (age >= 18) {
  console.log("Adult");
} else {
  console.log("Minor");
}

// 여러 조건 확인 (if-else if-else)
const score = 85;

if (score >= 90) {
  console.log("Grade: A");
} else if (score >= 80) {
  console.log("Grade: B");
} else if (score >= 70) {
  console.log("Grade: C");
} else {
  console.log("Grade: F");
}

// TypeScript에서의 type narrowing
function process(value: string | number) {
  if (typeof value === "string") {
    // 이 block 내에서 value는 string type으로 처리됨
    return value.toUpperCase();
  } else {
    // 이 block 내에서 value는 number type으로 처리됨
    return value.toFixed(2);
  }
}

호텔 예약 시스템

• Airbnb system 설계
• 항공권 예약 system 설계
• 영화 ticket 예매 system 설계

1단계: 문제 이해 및 설계 범위 확정

아래 세부 사항은 가상 면접관과의 대화를 통해 문제를 이해하고, 설계 범위를 정의한 내용이다.

• 비기능 요구사항
  • 높은 수준의 동시성 (concurrency): 성수기, 대규모 event 기간에는 일부 인기 hotel의 특정 객실을 예약하려는 고객이 많이 몰릴 수 있음
  • 적절한 지연 시간: 사용자가 예약할 때 응답 시간이 빠르면 이상적이지만 예약 요청 처리에 몇 초 정도 소모되는 것은 괜찮음
• 개략적 규모 추정
  • 총 5,000개 hotel, 100만 개의 객실 가정
  • 평균적으로 객실의 70% 사용, 평균 투숙 기간은 3일로 가정
  • TPS (Transactions Per Second)
    • 일일 예약 건수 $=\frac{10^6\times0.7}{3}=233,333\simeq240,000$
    • 초당 예약 건수 $=\frac{240,000}{10^5}\simeq3$
  • QPS (Queries Per Second)
    • Hotel/객실 상세 page: 사용자가 hotel/객실 정보 확인 (조회 발생)
    • 예약 상세 정보 page: 사용자가 날짜, 투숙 인원, 결제 방법 등의 상세 정보를 예약 전 확인 (조회 발생)
    • 객실 예약 page: 사용자가 ‘예약’ button을 눌러 객실 예약 (Transaction 발생)
    • 대략 10%의 사용자가 다음 단계로 진행, 90%의 사용자는 이탈한다 가정
    • $\therefore$ $3\ (TPS) * 10 * 10 = 300\ (QPS)$