TypeScript 미드레벨 시스템 설계 면접

RESTful API는 리소스의 상태를 HTTP 메서드로 조작하는 방식이고, RPC 스타일은 동작(action)을 URL에 명시하는 방식입니다. 주문 취소는 단순 상태 변경이 아니라 재고 복구, 결제 취소, 알림 발송 등 복잡한 비즈니스 로직을 포함하므로 POST /orders/{id}/cancel이 더 적합합니다. 단순 필드 업데이트는 PATCH를 사용하고, 복잡한 비즈니스 트랜잭션은 명시적인 액션 엔드포인트를 사용하는 것이 의도를 명확히 전달합니다. TypeScript에서는 각 엔드포인트의 요청/응답 타입을 명확히 정의하여 API 계약을 강제할 수 있습니다.

현재 가격을 products 테이블에 중복 저장하는 방식은 조회 성능이 우수하지만 데이터 정합성 관리가 필요하고, 이력 테이블만 사용하는 방식은 정합성은 보장되지만 매번 최신 레코드를 찾는 조인이 필요합니다. 실무에서는 읽기 성능이 중요하므로 현재 가격을 중복 저장하고 트랜잭션으로 정합성을 보장하는 방식을 선호합니다. TypeScript ORM에서는 @AfterInsert, @AfterUpdate 같은 엔티티 리스너나 트랜잭션 데코레이터를 활용해 가격 변경 시 이력 자동 생성과 현재 가격 업데이트를 원자적으로 처리합니다. Prisma에서는 $transaction API로 여러 쿼리를 묶어 처리할 수 있습니다.

Cache-Aside는 애플리케이션이 캐시를 직접 관리하며 캐시 미스 시 DB 조회 후 캐시에 저장하는 방식이고, Write-Through는 쓰기 시 캐시와 DB를 동시에 업데이트하는 방식입니다. 피드 시스템은 읽기가 압도적으로 많고 실시간성이 중요하므로 Cache-Aside가 적합하며, 새 게시물 작성 시 팔로워의 캐시를 즉시 무효화하거나 TTL을 짧게 설정합니다. TypeScript에서는 메서드 데코레이터로 @Cacheable(key, ttl)을 구현하여 Redis 조회/저장 로직을 추상화하고, 제네릭 타입으로 캐시 데이터의 타입 안정성을 보장할 수 있습니다. ioredis 같은 라이브러리와 결합하여 파이프라인, 트랜잭션도 지원 가능합니다.

Orchestration은 중앙 조정자가 각 서비스를 순차적으로 호출하며 트랜잭션을 관리하는 방식이고, Choreography는 각 서비스가 이벤트를 발행하고 구독하며 분산 방식으로 트랜잭션을 진행하는 방식입니다. Orchestration은 플로우가 명확하지만 단일 장애점이 생기고, Choreography는 느슨한 결합이지만 디버깅이 어렵습니다. RabbitMQ는 복잡한 라우팅과 재시도가 필요한 Orchestration에 적합하고, Kafka는 이벤트 스트림과 순서 보장이 중요한 Choreography에 적합합니다. TypeScript에서는 각 단계의 상태를 타입으로 정의하고, 실패 시 이전 단계의 보상 트랜잭션을 실행하는 State Machine을 구현하며, 멱등성 키로 중복 처리를 방지합니다.

Access Token은 짧은 만료 시간으로 탈취 위험을 최소화하고, Refresh Token은 긴 만료 시간으로 사용자 편의성을 제공하며 서버에서 무효화 가능하도록 분리합니다. Refresh Token Rotation은 토큰 사용 시마다 새 토큰을 발급하고 이전 토큰을 무효화하여 토큰 재사용 공격을 방지합니다. TypeScript 미들웨어에서는 동시에 여러 요청이 토큰 갱신을 시도할 때 Redis의 SETNX나 분산 락을 사용해 한 번만 갱신되도록 보장하고, 갱신 중인 요청은 대기 후 새 토큰을 받도록 구현합니다. 타입 가드로 토큰 페이로드 검증을 강화하고, 환경변수로 비밀키를 관리합니다.