안녕하세요. 오늘 KTX 경부선 설명절 티켓 예매가 있었죠.

저도 오전 7시에 대기하고 있다가 바로 예매를 신청했는데요.

최대한 빨리 클릭했는데 이 대기 순서가 50만 번대고요. 제 뒤에 거의 뭐 200만 명 정도 이렇게 많은 대기 수가 있네요.

그래서 오늘은 이 대용량 트래픽을 유발하는 이런 어떤 선착순 예매 시스템을 구현하려면 어떤 아키텍처로 설계하면 좋을지 한번 말씀드려 보겠습니다.

참고로 뭐 모든 구체적인 걸 다 말씀드릴 수 없고요.

아키텍처를 크게 세 단계로 나눠서 좀 추상화시켜서 좀 핵심만 말씀드려 보겠습니다.

보통 API의 가장 단순한 모습, 백엔드의 가장 단순한 모습은 이런 형태죠.

사용자가 요청하면 API 한 대가 데이터베이스하고 연동해서 이렇게 값을 반환하는 구조죠.

근데 사용자 수가 많아지면 이 패를 확장하죠.

그리고 앞단에 로드 밸런서나 API 게이트웨이를 두고 사용하고 통신하고 부하를 이렇게 분산하죠.

그런데 이 예매 시스템 같은 경우, 이 설명절 KTX 예매는 굉장히 많은 사람이 동시에 접속하죠.

오전 7시에 시작하면 예매하는 사람은 이때 전부 다 클릭하게 됩니다.

아까 그 대기표에서도 보셨듯이 제가 50만 번대였고요.

제 뒤에 거의 200만 명이 대기하고 있었죠. 이런 트래픽 규모에서는 이 데이터베이스가 견디지 못합니다.

API를 아무리 스케일 아웃해도 결국 예매를 처리하는 데이터베이스, 뭐 좀 분리는 한다 치더라도 DB가 거의 뻗을 확률이 굉장히 높습니다.

그렇다고 DB를 무한정 스케일 아웃하기는 같은 경우는 RDB거든요.

최종 예매 시스템은 데이터 정합성이나 무결성 같은 것들이 잘 보장이 돼야 되기 때문에 NoSQL을 잘 안 쓰죠.

RDB는 스케일 아웃하기도 힘들고 스케일업의 비용은 굉장히 많이 증가하죠.

설령 그렇게 한다고 해도 이렇게 수백만 요청, 동시 요청을 처리하기 힘듭니다.

RDB 가지고는 그래서 새로운 아키텍처가 필요한 거죠.

이러한 대용량 트래픽이 예매 시스템 같은 경우에는 일단 트래픽이 굉장히 많죠.

동시에 수십만, 수백만이 요청을 하죠.

그리고 선착순으로 돼야 되기 때문에 순서가 보장이 돼야 되죠.

먼저 들어온 사람이 먼저 예매할 수 있도록 보장을 해야 되고 그리고 좌석수, KTX의 좌석수를 넘지 않도록 초과 예매가 안 돼야 되죠.

그리고 서로 다른 사람이 같은 자리 혹은 같은 시간대를 예매할 수 없도록 중복 예매가 방지돼야 되죠.

그래서 이런 어떤 대용량 선착순 예매 시스템 같은 경우 어떤 식으로 설계를 하는지 좀 보겠습니다.

다만 제가 구체적으로 하나하나 어떤 집기보다는 이 아키텍처 관점에서 좀 추상화해서 추상화 아시죠?

제가 이전 강의에도 말씀드렸죠.

핵심만 아키텍처 측면에서 핵심만 같이 한번 설계를 어떻게 하는지 한번 보겠습니다.

통상 이런 경우 세 단계로 문제를 분리해서 설계를 합니다.

먼저 모든 요청이 데이터베이스로 바로 가지 못하도록 앞단에 대기열에 먼저 등록을 시켜요.

대기열 등록은 인메모리 시스템에 등록을 시키죠.

이게 1번이고 2번. 그다음에 대기열에서 선착순으로 예매를 할 수 있는 곳으로 입장을 시켜요.

대기열은 계속 쌓여 있겠죠. 수백만이.

그러다가 일부를 예매로 돌립니다. 순서대로. 예. 이게 예매 입장이고요.

그리고 예매 처리. 아, 입장해 가지고 실제 RDB에 들어가도록 예매 처리하는 것. 이렇게 좀 단순화시키면 세 개의 단계로 구분할 수 있습니다.

아, 모든 순간적인 트래픽 동시 요청들이 DB로 바로 갈 수 없도록 대기열을 만드는데요.

요즘은 레디스가 그 대기열에 가장 적합한 어떤 솔루션이라서 많이 사용하고 있어요.

어, API가 이렇게 있죠. 요대.요 요 앞에는 사용자고요.

로드 분배하겠죠. 여기 뒤에 레디스를 넣는 거죠. 이 레디스가 대기열 역할을 합니다.

레디스의 지셋 이게 뭐죠? 정렬 정렬 셋이죠.

정렬 셋이라는 자료 구조를 이용합니다.

처음에 사용자가 예약 시작하면 어 KTX 같은 경우도 처음에 로그인은 안 시키거든요. 바로 로그인이 되지 않은 상태에서 바로 예약 접수라는 버튼을 누릅니다.

그러면 API에서 그걸 받아서 UUID라는 고유값을 만들어서 이게 사용자 식별값이에요.

아직 로그인이 되지 않았기 때문에 아이디라는 식별자 값을 만들어서 레디스에 이 소티드 셋에 저장을 합니다.

그리고 시간 타임스탬프 이렇게 하면 이 타임스탬프로 자동으로 정렬이 되죠.

들어온 순서대로 이 사용자가 이 시간에 들어왔다.

그래서 들어온 순서대로 쭉 정렬이 되죠.

그리고 API는 레디스에 그렇게 놓고 나서 사용자에게 반환합니다. 그리고 사용자는 다음 요청부터는 UUID를 들고 오죠.

그 이후에 사용자 브라우저와 이 API 같은 경우에는 보통 폴링 아니면 SSE, 서버 센트 이벤트죠.

어, 이런 것들 중에 하나를 사용해서 계속 대기열 상태 아까 그 대기표 보셨죠?

그게 계속 업데이트되거든요. 내가 지금 몇 번째 있고 내 몇 번째 있고 계속 줄어들죠.

웹소켓은 혹시나 네트워크 장비 단에서 거부될 가능성도 있어서 그래서 사용자가 엄청난 트래픽을 보내면 API들이 다 받아서 이 레디스 여기도 클러스터로 구성되죠.

단일 서버가 아니고 레디스 클러스터로 다 보내요.

그럼 레디스는 굉장히 빠르잖아요. 메모리 기반으로 움직이기 때문에.

그래서 레디스의 소티드 셋에 타임스탬프와 함께 사용자 유효 아이디를 저장해 둡니다.

그러면 백단에서 스케줄러가 돌아요.

뭐 1초에 한 번씩, 1초에 한 번씩 레디스를, 레디스에 있는 그 대기열에 있는 앞에서부터 몇 명까지 꺼내 가요.

그 몇 명까지의 기준은 어 이 백단에 그 예약 처리하는 시스템이 있을 거잖아요.

그 예약 처리 시스템, 그러니까 RDB는 예약 처리 시스템의 TPS, 초당 어 TPS가 얼마더라.

그래서 그 TPS보다 조금 더 여유 있게 만일에 백단의 어떤 이 예약 시스템이 초당 한 100건 정도 트랜잭션을 처리할 수 있다 그러면 어 뭐 한 7, 80건 뭐 6, 70건 정도를 받도록 한다고 했을 때 스케줄러는 대기열을 주기적으로 체크하면서 앞에서부터 뭐 60건 정도를 한 번에 가져가죠.

이 이 레디스가 좋은 게 이 브라우저 사용자 단한테 내가 몇 번째 있는지 계속 줄여주는 거 있잖아요.

그 연산을 그냥 ZRANK 그리고 전체 대기자 수는 ZCARD로 바로 아주 빠르게 가져갈 수 있고요.

잠시 좀 지웠다가 다시 좀 할게요. 이렇게 사용자가 액티브 유저에 있는 걸 체크되면 예매 API로 리다이렉션, 그니까 요청을 예매 API로 보내죠.

그러면 이 대기열 서버와 또 다른 API 예매 서버에서 예매를 진행하게 됩니다.

어, KTX 같은 경우에는 시간대 별로 해서 예매 수량 n개의 좌석수를 예매하도록 되어 있어요.

그래서 여기에 총 좌석보다 그 예매하는 수량이 초과되지 않도록 동시성 처리를 제어를 해 줘야 되는데요.

어, RDB의 락을 사용할 수도 있지만 어, 그렇다면 또 RDB가 부하를 받을 수 있으니까 이때도 역시 레디스의 어떤 원자적인, 아토믹한 연산을 이용해서 동시성 제어를 하는 게 좋습니다.

보통 루아 스크립트로 로직을 짜서 이 로직이 원자적으로, 그러니까 멀티 스레드 환경에서도 어 중간에 트랜잭션이 개입되지 않도록 원자적 작업을 수행하는 스크립트를 만듭니다.

여기서 어 현재 잔여 좌석을 조회하고 요청 좌석보다 잔여 좌석수가 많거나 같으면 해당 예약 신청자의 자리수, 그러니까 요청 개수죠.

요청 좌석수죠. 자리수만큼이 조건이 성립하면 성공으로 반환하죠.

만일 누군가가 약간 늦어서 그 시간대에 요청 수보다 잔여 좌석수가 부족하게 되면 실패로 처리합니다.

이 루아 스크립트의 실행 과정은 원자적으로 실행되기 때문에 어 멀티스레드 환경에서도 안전하죠.

그리고 이렇게 성공한 어떤 요청은 바로 RDB로, 그 API를 통해서 실제 아키텍처에 있는 RDB 그쪽으로 넣을 수도 있고 아니면 여기서 또 한번 부활을 좀 방지하려면 여기서도 MQ가 들어갈 수도 있어요.

그래서 요청 좌석수가 성공한 요청을 API가 MQ에 쓰고 바로 반환. 그리고 MQ에서는 백단의 워커가 빼서 DB에 저장하고 완료시키는 거죠.

어, 실제 이 과정에서 복잡한 건 최대한 제거하는 게 좋아요. 이 지금 KTX 예약도 보면 결제는 하지 않도록 되어 있어요.

좌석 예매까지만 이렇게 진행하거든요.

문제가 좀 더 심플해지잖아요. 결제까지 하면 중간에 그 예외 사항들이 굉장히 많아져요.

결제했다가 돌아오는 그 과정에서 어떤 뭐 실패 처리 그런 것들.

그래서 어 결제를 뒤로 미루면 결제 같은 경우에는 좌석 수만큼만 요청이 있을 테니까 수백만, 수십만 되지 않을 거잖아요.

그래서 결제는 훨씬 가벼운 시스템이 되는 거죠. 그래서 결제라는 건 제외하고 예매까지만 하는 거고.

그리고 참고로 이 레디스에 이 스케줄러에서 뭐 100명 100개씩 뽑아서 예매 입장 가능하도록 처리할 때도 레디스에 넣을 때 이 타임아웃 시간을 넣어요.

그래서 예매 입장으로 돌렸는데 너무 오래 걸리거나 아무것도 일도 하지 않는 채 떠나간 사람 있죠.

그냥 브라우저 켠 상태로. 그 사람들은 이 제한 시간 내에 어떤 액션 없거나 아니면 절대적인 제한 시간을 줘서 빠져나가도록 자동으로 떨어져 나가도록 하는 것도 추가를 구현합니다.

이 KTX 같은 경우는 3분이더라고요.

3분 사이에 막 뭘 해도 3분이 지나가면 튕겨 버려요. 이 레디스 액티브 유저 할 때 3분 해 놓으면 자동으로 없어지죠.

그러면 이 API 계속 체크할 때 액티브 유저 없으니까 튕겨내 버리면 되는 거죠.

다시 좀 최종 정리를 좀 할게요. 중간에 그 액티브 유저 넣는 부분이 약간 좀 잘린 거 같아요.

1번 대기열에 저장하는 거. 그리고 스케줄러가 입장 처리하는 것.

마지막으로, 실제 예매 처리해서 RDB에 저장하는 것.

먼저 사용자가 7시에 수백만 명이 접수를 해요. 신청을 하죠. 그러면 요청이 쫙 API가 받을 거예요.

그럼 API들이 DB로 보내면 DB가 뻗죠.

그 DB로 안 보내고 일단 대기열 레디스로 다 보냅니다. 그럼 레디스에서는 소티드 셋에 타임스탬프하고 UUID, 사용자 식별값이죠.

UUID하고 타임스탬프를 소티드 셋에 저장합니다.

그럼 자동으로 정리되죠. 레디스 자료 구조에 의해서. 그렇게 계속 쌓이고요.

사용자가 계속 요청하면 계속 쌓입니다. 대기열에는 이 레디스는 클러스터로 구성돼야 되겠죠.

그리고 스케줄러가 백단에서 뭐 1초에 한 번, 뭐 더 짧게 할 수도 있고요, 더 길게 할 수도 있고요.

수백만 동시 접속을 처리하는 예매 시스템 아키텍처 설계

코딩하는기술사

수백만 건의 동시 접속을 처리하는 예매 시스템은 데이터베이스의 부하를 줄이기 위해 대기열(레디스 Sorted Set 활용) → 예매 입장 처리(스케줄러와 Active User 목록 활용) → 실제 예매 처리(레디스 루아 스크립트로 좌석 동시성 제어)의 3단계로 설계됩니다.

대기열 단계에서는 사용자의 고유 식별자(UUID)와 타임스탬프를 레디스 Sorted Set에 저장하여 요청 순서를 보장하고, 클라이언트에게 실시간 대기 순번을 제공합니다.

예매 처리 단계에서는 레디스의 원자적 연산(루아 스크립트)을 사용하여 좌석의 잔여 수량을 안전하게 관리하고 초과 예매 및 중복 예매를 방지하며, 성공한 요청은 최종적으로 RDB에 저장하거나 MQ를 통해 비동기 처리하여 시스템 부하를 추가로 완화할 수 있습니다.

설날 KTX 예매는 수백만 명의 사용자가 동시에 접속하여 엄청난 양의 트래픽을 유발합니다. 오전 7시 예매 시작과 동시에 모든 사용자가 클릭하는 순간, **50만 번째 대기열에 200만 명 이상의 대기자가 발생할 정도로 트래픽이 집중**됩니다. 이러한 규모의 동시 요청은 일반적인 데이터베이스로는 감당하기 어렵습니다.

API를 확장(스케일 아웃)하더라도, 결국 예매 처리를 담당하는 관계형 데이터베이스(RDB)는 부하를 견디지 못하고 뻗을 가능성이 높습니다. RDB는 데이터의 정합성과 무결성을 보장해야 하므로 NoSQL을 사용하기 어렵고, **스케일 아웃이나 스케일 업에도 한계가 있어 수백만 동시 요청을 처리하기에는 부적합**합니다. 따라서 이러한 대용량 트래픽을 처리하기 위한 새로운 아키텍처가 필요합니다.

대용량 선착순 예매 시스템의 요구사항

대용량 트래픽을 처리하는 선착순 예매 시스템은 몇 가지 핵심 요구사항을 충족해야 합니다. 첫째, **수십만에서 수백만 건의 동시 요청을 안정적으로 처리**해야 합니다. 둘째, 선착순 원칙에 따라 먼저 요청한 사용자에게 예매 기회가 보장되어야 합니다. 셋째, KTX 좌석 수를 초과하는 예매가 발생하지 않도록 해야 하며, 넷째, 서로 다른 사용자가 같은 좌석이나 시간대를 중복 예매할 수 없도록 방지해야 합니다. 이러한 요구사항을 만족시키기 위해 아키텍처는 세 단계로 분리되어 설계됩니다.

세 단계로 구성된 아키텍처 설계

대용량 선착순 예매 시스템은 **모든 요청이 데이터베이스로 바로 가지 않도록 세 단계로 문제를 분리하여 설계**됩니다. 첫 번째 단계는 '대기열 등록'으로, 모든 요청을 인메모리 시스템의 대기열에 먼저 등록하는 것입니다. 두 번째 단계는 '예매 입장'으로, 대기열에 쌓인 사용자 중 일부를 선착순으로 실제 예매를 할 수 있는 시스템으로 입장시키는 것입니다. 마지막 세 번째 단계는 '예매 처리'로, 입장한 사용자가 RDB에 실제 예매 정보를 저장하는 과정입니다.

1단계: 레디스를 활용한 대기열 시스템

**순간적인 동시 요청이 DB로 바로 전달되는 것을 막기 위해 레디스를 대기열 시스템으로 활용**합니다. 사용자가 예약을 시작하면, API는 고유 식별값(UUID)을 생성하여 레디스의 Sorted Set 자료구조에 타임스탬프와 함께 저장합니다. 이를 통해 요청이 들어온 순서대로 자동으로 정렬되며, API는 사용자에게 UUID를 반환합니다. 이후 사용자 브라우저는 폴링(Polling), SSE(Server-Sent Events) 또는 웹소켓을 이용해 계속해서 자신의 대기열 상태(순번)를 업데이트 받습니다.

수많은 사용자의 요청이 API를 통해 레디스 클러스터로 전달되며, 메모리 기반인 레디스는 이 요청들을 매우 빠르게 처리합니다. **레디스의 ZRANK 연산을 통해 자신의 대기 순번을, ZCARD 연산을 통해 전체 대기자 수를 신속하게 조회**하여 사용자에게 실시간 대기 상태를 제공합니다.

2단계: 스케줄러를 통한 예매 입장 제어

백단에서는 스케줄러가 주기적으로(예: 1초에 한 번) 레디스 대기열을 확인하여 앞에서부터 일정 수의 사용자를 '액티브 유저' 목록으로 이동시킵니다. 이 '일정 수'는 **예약 처리 시스템(RDB)의 초당 트랜잭션 처리량(TPS)을 고려하여 결정**되며, 예를 들어 TPS가 100건이라면 약 60~80건 정도의 요청을 한 번에 처리하도록 조절합니다. 이 액티브 유저 목록 역시 메모리에 저장되어 빠르게 접근 가능합니다. 또한, '액티브 유저' 목록에 있는 사용자가 일정 시간(예: 3분) 내에 아무런 액션이 없으면 자동으로 목록에서 제외하여 불필요한 자원 점유를 방지합니다.

사용자가 자신의 상태를 폴링으로 체크하다가 액티브 유저 목록에 포함되면, 예매 API로 리다이렉션되어 실제 예매 화면으로 진입할 수 있게 됩니다. **이를 통해 DB로 향하는 트래픽이 스케줄러에 의해 통제되어 과부하를 방지**합니다.

3단계: 레디스와 MQ를 활용한 예매 처리

예매 서버에서는 KTX의 시간대별 좌석수를 초과하지 않도록 **동시성 처리가 중요**합니다. RDB 락 대신 레디스의 원자적인 연산을 활용하여 동시성을 제어하는 것이 효과적입니다. 루아(Lua) 스크립트를 사용하여 현재 잔여 좌석을 조회하고, 요청 좌석 수와 비교하여 충분하면 해당 좌석수를 차감하는 로직을 원자적으로 실행합니다. 이 루아 스크립트는 멀티스레드 환경에서도 안전하게 작동하여 중복 예매를 방지합니다.

예매 성공 요청은 바로 RDB에 저장될 수도 있지만, **부하 분산을 위해 메시지 큐(MQ)를 활용**할 수 있습니다. API는 성공 요청을 MQ에 쓰고 즉시 사용자에게 예매 성공을 반환하며, 백단의 워커가 MQ에서 메시지를 가져와 RDB에 최종적으로 저장합니다. KTX 예매 시스템의 경우 결제 과정을 분리하여 예매까지만 처리함으로써 시스템 복잡성을 줄이고 부하를 완화합니다. 결제는 예매된 좌석 수만큼만 발생하므로 비교적 가벼운 시스템으로 처리할 수 있습니다.

결론: 대용량 예매 시스템 아키텍처 요약

대용량 동시 요청을 처리하는 예매 시스템은 **세 단계로 구성된 아키텍처를 통해 안정적으로 구현**됩니다. 첫째, 모든 동시 요청은 레디스 클러스터의 Sorted Set 기반 대기열에 먼저 등록됩니다. 둘째, 백단의 스케줄러가 RDB의 처리 가능량을 고려하여 대기열에서 적정 수의 사용자를 '액티브 유저'로 선별하여 예매 시스템에 입장시킵니다. 셋째, 입장한 사용자의 예매 요청은 레디스의 루아 스크립트를 이용한 원자적 연산을 통해 좌석 수를 차감하고, 최종적으로 RDB에 저장되거나 MQ를 거쳐 저장됩니다. 이러한 분산 및 제어 메커니즘을 통해 수백만 동시 접속 환경에서도 안정적인 선착순 예매를 구현할 수 있습니다.

KTX 설명절 티켓 예매와 같은 대용량 트래픽을 처리하는 시스템 아키텍처를 설계할 때, 일반적인 API 및 데이터베이스 구성으로는 왜 한계가 발생하는지 설명해 주세요.

대용량 선착순 예매 시스템이 충족해야 하는 주요 요건(예: 동시 접속 처리, 순서 보장, 초과/중복 예매 방지)은 무엇이며, 이러한 요건들을 어떻게 아키텍처에 반영할 수 있을까요?

제안된 세 단계 아키텍처(대기열 등록, 예매 입장, 예매 처리)에서 Redis가 어떤 핵심적인 역할을 하며, 각 단계에서 Redis의 구체적인 활용 방안(예: 자료 구조, 연산)에 대해 자세히 설명해 주세요.

예매 시스템에서 동시성 제어를 위해 RDB 락 대신 Redis의 원자적 연산을 활용하는 방법은 무엇이며, 특히 Lua 스크립트를 사용하는 이유와 그 작동 방식에 대해 설명해 주세요.

결제 시스템을 예매 과정과 분리하여 설계하는 것이 시스템 부하를 줄이는 데 어떤 이점이 있으며, KTX 예매 시스템에서 결제를 후순위로 미루는 전략의 효과는 무엇인가요?

대용량 트래픽 예매 시스템 아키텍처 설계 배경

KTX 명절 예매 경험을 통해 대기 순서가 50만 번대에 이르는 대규모 트래픽 발생 확인.

대용량 트래픽을 유발하는 선착순 예매 시스템 구현을 위한 아키텍처 설계의 필요성 제기.

아키텍처를 세 단계로 추상화하여 핵심만 설명할 계획.

기존 시스템의 한계점 및 대용량 트래픽 예매 시스템의 특징

일반적인 API-DB 연동 방식은 사용자 수 증가 시 API 확장을 통해 부하를 분산하지만, 동시 접속자 수가 매우 많은 예매 시스템에는 부적합.

수백만 동시 접속 시 데이터베이스가 부하를 견디지 못하며, RDB는 무한정 스케일 아웃이 어렵고 비용이 많이 들어 새로운 아키텍처 필요.

대용량 선착순 예매 시스템은 수십만~수백만의 동시 요청 처리, 선착순 순서 보장, 좌석 초과 예매 방지, 중복 예매 방지 등의 요구사항이 있음.

대용량 선착순 예매 시스템의 3단계 설계

문제 해결을 위해 대기열 등록 (1단계), 예매 입장 (2단계), 예매 처리 (3단계) 세 단계로 분리하여 설계.

모든 요청이 DB로 바로 가지 않도록 앞단에 인메모리 시스템인 Redis를 대기열로 사용.

Redis의 Sorted Set 자료구조를 이용하여 사용자 UUID와 타임스탬프를 저장, 들어온 순서대로 정렬.

사용자 브라우저는 폴링, SSE, 웹소켓 등을 통해 대기열 상태를 계속 업데이트 받음 (폴링이 주로 사용됨).

API는 Redis 클러스터에 사용자 요청을 전달하여 빠른 처리를 가능하게 함.

2단계: 예매 입장 처리 (스케줄러 활용)

백단 스케줄러가 주기적으로 (예: 1초에 한 번) Redis 대기열에서 예약 처리 시스템의 TPS에 맞춰 적정 수의 사용자를 꺼냄.

Redis의 ZRANK와 ZCARD 명령으로 사용자 대기 순위 및 전체 대기자 수를 빠르게 조회.

3단계: 예매 처리 및 최종 저장 (Redis 원자적 연산 및 DB/MQ)

예매 API는 KTX 시간대별 좌석수를 관리하며, 초과 예매 방지를 위해 동시성 제어가 필수.

RDB 락 대신 Redis의 원자적인 연산 (Lua 스크립트)을 사용하여 잔여 좌석 조회 및 차감을 안전하게 처리.

예매 성공 요청은 RDB에 직접 저장하거나, 부하 방지를 위해 MQ에 먼저 쓰고 백단 워커가 DB에 저장하는 방식을 사용.

결제는 예매 시스템에서 분리하여 시스템 복잡성을 줄이고 부하를 완화.

예매 입장 시 타임아웃 시간을 두어 일정 시간 내에 액션이 없거나 이탈한 사용자를 자동 제외 (KTX의 경우 3분).

꺼내진 사용자들은 '액티브 유저'로 등록되어 예매 시스템으로 입장 가능한 상태가 됨.

사용자는 폴링을 통해 액티브 유저 상태를 확인하고 예매 폼으로 이동하여 좌석 선택.