비즈니스가 요구하는 보장 수준을 먼저 판단하라같은 알림이 2번 오면?수강 신청 알림이 사용자에게 2번 도착했다. "수강 신청이 승인되었습니다"가 2번.버그인가 ? 허용 가능한 비용인가 ?>>내 답은 허용 가능한 비용이다.수강 신청은 했든 안 했든 여부의 문제다. 2번 알림이 와도 "아, 승인됐구나"로 끝난다. 비즈니스적으로 손해가 없다. 그런데 100번 오면 ? 사용자 폰에 같은 푸시가 100개 쌓여 있으면 ?비즈니스적으로는 여전히 "한 번 승인된 건 승인된 거"다. 하지만 사용자 경험 관점에서는 버그(라고 판단할 것이)다.체감상 2번까지는 "시스템 이슈겠지" 하고 넘어가지만, 3번부터는 짜증이 나고, 그 이상이면 앱을 삭제할 수 있다. "2번은 OK, 100번은 NO"라는 기준이 생기는데 — 그 경계는..

AI의 많은 도움을 받았습니다 .. AWS(Amazon Web Services)를 처음 접하거나 아키텍처를 설계하다 보면, 쏟아지는 수많은 알파벳 약어와 독특한 서비스 이름들에 당황하기 마련입니다. 하지만 이 이름들은 단순히 무작위로 지어진 것이 아닙니다.이름 속에는 개발자들만 아는 위트, 서비스의 본질, 심지어 경쟁사를 향한 도발적인 메시지까지 숨어있습니다. 알고 나면 클라우드 아키텍처가 훨씬 더 직관적으로 다가오는 AWS 서비스 네이밍의 유래와 숨은 이야기들을 정리해 보았습니다.(💡 이 글은 새로운 AWS 서비스를 공부할 때마다 지속해서 업데이트되는 문서입니다.)1. 덧셈 공식: 앞 글자가 같으면 숫자로 압축하라! 🔢AWS의 가장 대표적인 서비스들은 앞 글자의 알파벳 개수를 숫자로 압축하여 부르는..

좋습니다. 가장 근본부터 시작합니다.Phase 0: 왜 클라우드인가0-1. 출발점 — 물리 서버 시대의 고통클라우드를 이해하려면 "클라우드가 없던 시절의 문제"부터 봐야 합니다. 해결책(클라우드)을 먼저 보면 "왜 이렇게 만들었는지"가 안 보이니까요.2005년, 당신이 온라인 쇼핑몰을 런칭한다고 가정합니다.서버를 확보하는 과정:IDC(인터넷 데이터센터)에 랙 공간을 계약합니다. Dell이나 HP에 서버를 주문합니다. 배송에 2~4주. 도착하면 랙에 장착하고, 네트워크 케이블 연결하고, OS 설치하고, 미들웨어 깔고, 보안 패치하고, 방화벽 설정합니다. 여기까지 빠르면 4주, 느리면 8주입니다.핵심 문제 3가지가 발생합니다.① 용량 예측의 딜레마 (Capacity Planning Paradox)블랙프라이데..

세션 프로토콜 확인했습니다. 프레임워크가 명확하니 바로 들어가겠습니다.[Phase 0: 진입 질문 — 근본적 물리적 병목 식별]Elasticsearch(그리고 그 코어인 Apache Lucene)가 세상에 나오기 이전의 세계를 상상해 봅시다.2004년, 당신이 100만 개의 게시글이 담긴 PostgreSQL 테이블에서 WHERE content LIKE '%분산 트랜잭션%' 쿼리를 실행한다고 가정합니다.여기서 질문입니다:이 LIKE '%keyword%' 쿼리가 RDBMS의 B+Tree 인덱스를 전혀 활용하지 못하고 Full Table Scan으로 빠지는 이유를, 디스크 I/O와 B+Tree의 물리적 정렬 기준 관점에서 설명해 주세요.힌트를 하나 드리자면, B+Tree가 데이터를 정렬하는 축(axis)이 무..

님, 세션 프로토콜 확인했습니다. 바로 시작하겠습니다.[문제 정의] — 첫 번째 질문Kafka와 RabbitMQ를 본격적으로 파기 전에, 이 기술들이 왜 태어나야 했는지부터 짚겠습니다.아래 시나리오를 떠올려 보세요.주문 서비스가 결제 완료 후 재고 차감, 포인트 적립, 알림 발송, 정산 기록 4개의 후속 작업을 처리해야 합니다. 가장 단순한 구현은 주문 서비스가 4개의 하위 서비스를 동기 HTTP 호출로 순차 실행하는 것입니다.이 동기 직접 호출(Synchronous Direct Call) 아키텍처가 트래픽이 늘어날 때 부딪히는 물리적 병목은 크게 세 가지 축으로 나눌 수 있습니다.님에게 묻겠습니다:"동기 직접 호출 방식이 대규모 트래픽에서 한계에 부딪히는 근본적인 물리적 병목 3가지를 꼽고, 각각이 왜..

좋습니다. 바로 첫 질문 들어갑니다.첫 번째 질문: 근본적 병목 식별Redis Geospatial과 Redisson Reentrant Distributed Lock — 이 두 기술은 해결하려는 도메인이 다르지만, 공통적으로 하나의 물리적 병목을 전제로 태어났습니다.질문을 두 파트로 나누겠습니다.Part A — Geospatial"내 반경 3km 안의 가게를 찾아줘"라는 쿼리를 RDBMS(예: PostgreSQL + PostGIS 없이, 순수 B-Tree 인덱스)로 처리한다고 가정합시다. WHERE latitude BETWEEN ? AND ? AND longitude BETWEEN ? AND ? 형태의 범위 쿼리를 날릴 겁니다.이때 디스크 I/O 관점에서 이 쿼리가 왜 대규모 트래픽(QPS 10,000+)..

웹 애플리케이션 서버(예: Spring Boot, NestJS)가 HTTP 요청 하나를 받아서 DB에서 데이터를 조회하고 응답을 돌려주는 과정에서, CPU는 대부분의 시간 동안 "무엇을 하고 있는가"?그리고 이 사실이 Java(Spring)의 "thread-per-request" 모델과 Node.js의 "single-thread event loop" 모델이 각각 탄생하게 된 근본적인 이유와 어떻게 연결되는지, 당신의 논리로 설명해 보세요.힌트: "CPU가 바쁜가, 아니면 놀고 있는가?"부터 시작하면 됩니다. 틀려도 괜찮습니다. 논리의 흐름이 중요합니다. 내 답변:CPU는 CPU 작업이 없는 이상 I/O 작업 시에 대부분의 시간 동안 유휴하게 된다 ..그러면 불필요하게 CPU 코어에 올라간 스레드가 놀게 ..

TOCTOU — 도메인 순수성과 동시성 안전성 사이의 긴장이 글의 출발점수강 신청 시스템에서 Lecture.enroll(Student)에 정원 검증을 캡슐화하려고 했다.도메인이 자신의 불변식을 직접 지키는 Rich Domain Model을 지향한 것.그런데 k6로 1만 명 동시 요청을 보내자, 정원 100명인 강의에 199명이 등록되었다.도메인 규칙은 좋았으나, 데이터 정합성이 깨져 버렸다 ..이 글은 그 틈 — 검증 시점과 실행 시점 사이의 간극(TOCTOU) — 을 다룬다.TOCTOU란 무엇인가Time of Check to Time of Use. "확인한 시점"과 "사용하는 시점" 사이에 상태가 바뀔 수 있다는 문제다.스레드 A: enrolledCount 조회 → 99 두 스레드가 동시에 같은 값(9..