Video: "좌석 잡아 두기"는 어떻게 구현할까? | 티켓 예매 좌석 선점, 실제로 어떻게 만들까
Channel: 코딩하는기술사
Duration: 24m 17s
Source: subtitle (auto, ko)
Transcript:
자, 실전 설계입니다. 선착순 예매 시스템에서이 좌석을 선점하고 만료 처리를 어떻게 하면 좋을지 간단하게 설계 좀 해 보겠습니다. 지난 시간에이 콘서트 티켓 내매 시스템 설계 과정을 같이 한번 봤었죠. 이때 하나의 좌석을 두고 여러 사람이 선점하려고 하죠.이 이 동시성 처리를 여러 가지 기법이 있었지만 우리는 원자적 조건부 갱신을 하기로 했었습니다. 그래서 이렇게 코리를 만들었는데요. 자, 여기 만료된 헬드 좌석 회수는 별도로 설계가 필요하다라고 마킹만 하고 따로 설명은 드리지 않았는데요. 구독자분이 이렇게 질문을 해 주셨습니다. 자, 만료된 헬드 좌석 회수는 별도 설계 필요라고 되어 있는데 보통 어떻게 회수하나요? 사용자가 좌석을 선택해 놓고 아무것도 안 하고 나가 버리면 어느 시점에이 헬드를 어베어블로 변경하는 업데이트를 실행해야 하나요? 1분에 한 번씩 헬드 시트를 업데이트하는 스케줄러가 필요한가요? 자, 아주 훌륭한 구독자입니다. 이렇게 회색으로 적어 놓은이 문구를 보고 질문을 하신 겁니다. 자, 그래서 오늘은이 구독자분의 질문에 답을 하면서도 이런 예매 시스템에서 좌석의 선점과 만료 처리를 어떻게 하면 좋을지에 대해서 하나의 설계 관점을 말씀을 드리겠습니다.

자, 여러 사람이 좌석을 막 선점하려고 하죠. 그때이 특정한 사람이 어떤 좌석을 먼저 선점했습니다. 그리고 나서 계속 또 다른 좌석을 선점할 수도 있겠죠. 이거 선택했다가 저거 선택했다가. 그리고 최종적으로 결제까지 완료가 돼야지 실제로이 좌석이 팔린 것이죠. 이렇게 처음 좌석을 선택하고 최종 완료될 때까지이 좌석 뭐 101번이라고 가정을 했는데요.이 A가 선택한 101번 좌석은 누구의 것이 되어야 될까요? 결제 완료 전까지이 구간이죠. 물론 A가 선택을 했으니까 A 좌석이긴 하겠죠. 자, 그런데이 A가 결제를 하지 않고 그냥 떠났다면 어떻게 해야 될까요? 또는이 서버가이 중간에 뻗어 버리면이 좌석은 어떻게 돼야 될까요? 그리고 결제를 했는데 어, 결제 응답을 받지 못하면 또 어떻게 해야 될까요? 자, 이렇게 특정 리소스의 선점과 체중 완료까지 시간이 걸리는 이런 시스템에서이 리소스의 선점과 만료를 어떻게 해야 될지 그 설계 방법에 한 가지 접근법을 말씀드리겠습니다. 자, 먼저 어, 가장 단순한 형태는 상태를 두 가지로 두는 거겠죠.

처음에는 업웨어 상태로 둬서 누구든지 선점 가능한 좌석이고 최종적으로 결제까지 완료하면 어, 판매가 됐다 이렇게 솔더 처리를 하는 거죠. 그래서이 좌석은 비어 있거나 혹은 팔렸거나 둘 중에 하나의 상태를 가집니다. 자, 아주 심플하지만 문제가 있을 수 있겠죠. 자, 결제에는 시간이 걸리죠. 처음에 선점 가능한 좌석에서 이미 팔린 좌석 사이에 결제 진행이라는 단계가 들어갑니다. 자,이 결제 진행은 몇 분 이상 걸릴 수가 있겠죠?이 중간 단계, 결제 진행 단계의 상태는 어떻게 해야 될까요? 판매 가능 상태로 둔다 그러면 결제 진행 중간에 다른 사람이 또이 좌석을 선점할 수 있겠죠. 그러면 중북 예매가 되기 때문에 안 되겠죠. 자, 그렇다고 해서이 판매 완료 솔드로이 중간 단계를 설정하면 중간에 결제를 실패하거나 혹은 아까 말씀드린 대로 중간에이 사용자가 결제 진행 단계에서 포기하거나 떠나 버리면이 좌석은 판매가 되지 않았음에도 판매가 되었다고 되어 버리는 거죠. 결국 판매 기회를 잃는 거죠. 그래서 일반적으로이 중간 단계를 두는 것이 좋습니다.

자, 이렇게 좌석을 잡아 놨다라고 해서 홀드 처리를 하는 것이고요. 그 상태를 헬드라고 만듭니다. 그래서이 헬드는 특정 사용자가 일정 시간 동안 가지고 있는 임시 점유권 같은 것으로 보면 됩니다. 자, 이렇게 중간에이 임시 점유권 헬드 상태를 두면 두 가지를 생각해 봐야 됩니다. 첫 번째 누가이 헬드 상태를 얻는가입니다. A와 B이 여러자가 같은 좌석을 동시에 선택을 하면 어떤 사용자에게 줘야 되냐 하는 문제죠. 결국 동시성 처리 문제입니다. 그리고 두 번째는 이렇게 헬드 상태를 언제 만료 끝내야 되는가 하는 것인데요. 결제가 정상적으로 완료되면 상관없지만 중간에 사용자가 떠났거나 결제가 실패하거나 이런 경우에 어떻게 이것을 되돌려야 되는지에 대한 만료 처리에 대한 문제인 거죠. 그래서 1번은 동시성 처리에 대한 문제이고 2번은 만료 처리에 대한 문제입니다. 자, 오늘 주제는 만료 처리에 대한 것입니다. 자, 그렇지만 어, 순서대로 동시성 처리 문제부터 한번 보겠습니다. 자, 두자가 있죠. 여기서 특정 좌석 101번을 동시에 예매하려고 합니다.

자, 그런데 A가이 좌석에 판매 가능 여부를 위해서 조회를 하겠죠. 자, 이때는 판매 가능 상태입니다. 그리고 나서 어, 판매 가능하니까 이제 점해야 되겠다 하고 데이터베이스에 쓰기 헬드 처리를 합니다. 자, 문제는이 중간이 T2 단계죠. 이게 시간의 흐름인데요.이 T2 단계에서 A가 읽고 난 뒤에 쓰기이 중간에 찰라에 다른 사용자 B가이 좌석을 다시 읽고 오는 거죠. 조회를 한 거죠. 그럼 아직이 A가 쓰기 전이기 때문에이 좌석은 여전히 사용 가능한 상태가 되겠죠. 그래서 B도이 좌석을 선점하려고 쓰기를 할 겁니다. 그런데이 중간에 이미 A가 헬드 상태를 바꾼 거죠. 자, 그러면 B도 나중에 헬드 상태로 바꾸면 A의 좌석을 덮어 써 버리게 되겠죠. A도 선점을 성공한 거고 B도 선점을 성공한 거지만 좌석은 하나이기 때문에 문제가 발생하는 거죠. 자, 이게 일반적인 다중 사용 환경에서 동시성 문제입니다. 어,이 동시성 문제를 보통 락으로 처리를 하죠. 데이터베이스의 락킹. 이전 시간에서도 우리가 봤었죠. 가장 보편적으로 락을 사용하는 방법 비관적 락이죠.

조회할 때 잠궈 놓고 조회하고 쓸 때까지 다른 사람들이 중복으로 쓰지 못하게 하는 거죠. 자, 비관적 락을 사용하면이 경합이 굉장히 많이 몰리면이 락의 대기 시간이 길어지고 하면 영목이 되기 쉽겠죠. 뭐 분상락도 하나의 대안일 수 있지만 인프라가 복잡해지죠. 그래서 우리 설계에서는이 조건부 업데이트 일종의 낙간적의 형태인데요. 하나의 코리 안에서 상태를 보고 그 상태 업데이트를 하는 거죠. 그래서이 여러 사람들이 동일한 좌석을 선택하는이 동시성 문제를 이번 설계에서는 조건부 업데이트로 하겠다라는 결정을 한 것이고요. 자, 이렇게 조건부 업데이트를 하면이 좌석이 사용 가능한 상태인지 그리고 내가 선점하겠다 이것을 판단과 석이 이것을 하나로 할 수가 있는 거죠. 자, 이게 그 하나로 하는 조건부 업데이트 콜입니다. 좌석을 업데이트 하는데 상태를 보는 거죠. 상태가 판매 가능한 상태이면 헬드 처리를 하겠다라는 거죠. 이때 만료 시간도 같이 기록을 합니다. 현재 시간으로부터 7분 동안 잡아두겠다는 것입니다. 자, 이렇게 해서이 코리의 결과가 나온다면 선점을 성공한 것이고요.이 코리의 결과가 하나도 없다.

그러면이 조건을 만족하지 못했기 때문에 다른 사람이 이미 선점을 한 것이죠. 그래서이 코리는 읽고 판단하고 쓰는이 세 가지 단계가 하나의 코리 안에 있기 때문에 원자적으로 실행될 수 있는 거죠. 다른 트랜잭션이 끼어둘 수 없기 때문에 안전하게 처리가 가능합니다. 자, 이렇게 헬드 처리를 둘 때 테이블 스키를 한번 보겠습니다. 자, 좌석 번호가 있고요. 그리고 상태가 있습니다.이 상태는 사용 가능 헬드 솔드 중간에 헬드 상태가 임시 점유권 상태가 포함된 거죠. 그리고이 선점 트랜잭션에 대한 고유값입니다. 그리고 헬드바이는 누가 선점을 했는지 사용자 아이디 참조값을 넣고요. 그리고 헬드 언틸은 앞서 7분 만료 시간을 둔 것처럼이 선점이 유지되는 시간입니다. 자, 참고로이 좌석 번호가 지금 빅인트로 되어 있는데요. 좌석이 아주 많지 않은 경우에는 조금 낭비일 수 있죠.이 이 타입이 뭐 요즘은이 메모리 가격이 많이 다운되어서 크게 문제가 될 소지는 없겠지만 그래도 이왕이면 아끼는게 좋겠죠. 자, 이렇게 해서이 동시성 처리 문제는 해결을 했습니다.

자, 이제 본격적인 주제인 만료 처리 문제입니다. 자,이 헬드는 시간 제한이 있는 임시 권리라고 말씀을 드렸습니다. 자, 보통 우리이 분산 시스템에서 1등 시간 동안 자원 사용 권한을 부여하고 나서 그 시간이 지나면이 권한을 사라지게 만드는 구조를 리스라고 표현합니다. 자, 그러면 이렇게 임시로 잡아두는 시간을 얼마 정도로 두는게 좋을까요? 자, 결제 같은 경우에는 뭐 결제창 이동하고 뭐 카드 인증 앱 전환 할 수도 있고 뭐 한도 카드 교체도 할 수 있고 뭐 간편 결제 비밀번호 제시도 같은 것들을 할 수 있는 즉 시간이 많이 걸리는 작업이죠. 실제 피지 성인은 짧게 끝날지 몰라도 그 앞단에 사용자가 결제를 완료하는 과정 자체는 꽤 시간이 걸리는 과정입니다. 그런데 우리는이 시간을 유지를 해 줘야 되죠.이 이 사용자가 좌석을 선점하고 난 뒤에 결제가 완료될 때까지이 좌석이 다른 사람한테 뺏기면 안 되겠죠. 그래서이 시간을 몇 분으로 두는지에 대한 결정이 필요한데요. 뭐 이것은 딱히 딱 정해진 표준값이 있는 건 아닙니다.이 결제라는 행동 그리고 우리 비즈니스의 정책 그리고 시스템 특정 등을 보고 알맞은 값을 정하는 거죠.

어 인터파크를 보면 좌석 선택 단계에서는 최대 10분 그리고 결제 진행 단계에서는 7분의 선점 시간을 둔다고 하네요. 그리고 상품 유형이나 정책에 따라서이 시간이 달라지거나 아예 제한이 없을 수도 있다고 안내하고 있습니다. 자, 그래서 우리는 커리에서 이렇게 7분으로 가정을 하고 있고요. 자, 그러면이 7분이라는 선점 시간이 지나면 어떻게 될까요? 아무 일도 일어나지 않죠. 특별히 다른 걸 구현하지 않는 이상.이 만료 시간은 7분이죠. 우리가 지금 일단 저장한 값일뿐 스스로 상태를 바꿀 수는 없죠. 그래서 우리는이 만료를 체크해서 상태 변경을 하는 뭔가 로직을 추가를 해야 됩니다. 앞서 구독자 본 질문도 여기에 대한 질문이었던 거죠. 자, 그러면이 상태의 전이, 상태 변경이 어떻게 일어난지 케이스를 좀 보겠습니다. 자, 방금 말씀드린 사례가 여기네 번째 사례죠. 헬드 상태에서 7분이 지나면 판매 가능 상태로 바뀌어야 되는데 누가 바꿀지에서 알아보고요. 자, 첫 번째 판매 가능한 상태에서는 누구든지 선착순으로 먼저 접근 선점한 사람이 헬드 상태로 바꾸겠죠.

두 번째 이렇게 헬드 상태로 바뀐 것은 위에서 선점한 사람이 결제까지 다 완료하면 최종 판매 완료 솔더로 바뀌겠죠. 또 한편으로는 만일에 중간에 결제를 실패를 하면 혹은 본인이 결제를 취소하거나 명시적으로 결제가 거절되면 다시 판매 가능 상태로 돌려 줘야 되겠죠. 자, 여기이 앞에이 세 개의 상태 변경은이 사용자의 행동이 트리그가 되는 거죠. 다시 말해서 사용자의 행동에 따라서 이렇게 상태를 변경할 수가 있습니다. 자, 그렇지만 마지막 여기 만료 시간이 지났을 때 다시 판매 가능 상태로 바꾸는 것은 누가 해야 될까요? 자, 그래서 우리는 만료 처리 전략을 세워야 됩니다. 자, 그게 두 가지 전략을 구사할 수 있습니다. 자, 첫 번째지 만료입니다. 레이지 엑스레이션. 만료 시간은 일단 그대로 두고이 좌석을 조회할 때 혹은 다른 사람이 선점하려고 시도할 때 그 만료 시간을 보고 판매 가능 상태로 인식을 하는 거죠. 또 하나는 액티브 엑스플레이션. 자, 이것은 별도 스케줄러를 두는 방식입니다. 주기적으로 돌면서 만료된 좌석을 다시 판매 가능 상태로 바꿔 주는 어 워커를 두는 거죠.

스케줄러를. 자, 이것은 조금 시간차가 있을 수도 있겠죠. 스케줄러가 도는 시간이랑 만료 시간이랑 딱 일치를 하지 않을 수 있기 때문에. 자, 그런데 보통 우리 실무에서는이 지연 만료를 사용하는 것이 좋습니다. 보다 명확하죠. 다만이 지업 만료를 사용하면이 조회할 때 또는이 통계 쪽에서 집게 할 때도 만료 시간도 같이 봐야 되겠죠. 예를 들어서 인기가 없는 좌석은 다른 사람이 조회하거나 선점 요청하기 전까지는 만료 시간이 그대로 남아 있고 상태도 여전히 헬드 상태이기 때문에 요것을 감안을 해야 되겠죠. 자, 그리고이 지연 만료를 사용하더라도이 스케줄로도 같이 돌리는 것도 생각해 볼 수 있습니다. 뭐이 둘을 적절히 조합해서 사용하는 것을 권장을 드립니다. 자,이 좌석을 조회하거나 선점할 때이 좌석의 현재 상태를이 만료 시간까지 보고 판단을 정확하게 하고요. 별도이 스케줄로 해서 주기적으로 남은 것을 정리하는 거죠. 그래서 저도 답변을 그렇게 드렸습니다. 자, 지연 만료를 하면 앞서 봤던 그 좌석 선점 조건문을 조금 변경을 해야 됩니다.

자, 조건부 업데이트에서 기존에는이 상태만 봤었죠. 판매 가능한 상태인지만 봤었죠. 자, 그렇지만 지원 만료를 할 때는이 판매 가능한 상태뿐만 아니라이 헬드 상태에서 만료 시간이 지났는지도 같이 조건을 봐야 됩니다. 자, 이렇게 하면 헬드 상태지만 완료가 돼 버린 경우 또 판매가 가능하게 되는 거죠. 자, 그런데이 선점 만료하고 결제 완료가이 겹치는 순간은 어떻게 될까요? 자,이 사례를 보시죠. 18시 6분 59초에 피지 결제 성이 났습니다. 그런데 18시 7분에이 헬드 상태가 만료됐어요.이 헬드 상태가 만료되면 다른 사용자가 막 선점을 하려고 하겠죠. 그러면 선점을 해가 버리겠죠. 인기가 있는 자석일 경우에는. 자, 그런데 앞서이 결제 성인이 난 거니 우리한테 이렇게 응답을 준게 헬드 만료 시간 도달 이후라고 가정을 하는 거죠. 이런 식이죠. A라는 사용자가 선점을 했어요. 그리고 결제를 진행을 합니다. 그런데 선점 완료 시간은 여기였어요. 그런데 결제를 하고 나서이 외부의 피지사가 결제를 완료하고 난 뒤에 이때 우리한테 응답을 준 거죠.

그런데 이미 그 전에 만료가 됐기 때문에 사용자 B가이 좌석을 선점을 해 버린 거죠. 자, 이렇게 되면 A는 결제를 완료를 했는데 좌석을 선점 못 하게 되고 B는 다른 사람이 결제한 걸 선점하게 되죠. 중복 판매가 될 수도 있는 거죠. 자,이 시점에이 좌석이 A의 관점에서 솔더 상태인가요? B의 관점에서 판매 가능한 상태인가요? 자, 이것은 뭐 밀리초의 정밀도 문제는 아니죠.이 만료를 판정하는 쪽하고 결제를 확정하는 쪽이 서로 분리돼 있기 때문인 거죠. 다시 말해서 각각이 상대의 어떤 상태를 모른다는 것입니다. 뭐 이런 경우도 생각해 볼 수 있겠죠. 앞서서는 만료보다 뒤에 결제승인이 우리한테 콜백이 온 경우고요. 자, 타임아웃 나는 경우도 있겠죠. PG 결제는 성공했는데 네트워크가 지원돼서 타임아웃이 됐어요. 자, 상태를 못 받은 거죠, 우리는. 근데 PG 내부적으로는 성공을 한 거죠. PG는 외부 시스템이죠. 자, 이럴 때 우리는 이걸 또 뭘로 봐야 될까요? 우리 입장에서 타임아웃은 뭐 실패라고 단정 지을 순 없죠.

그냥 네트워크가 지원돼서 성공인지 실패인지 아예 모르는 상태인 거죠. 이런 경우이 만료 시간이 되면 어떻게 해야 될까요? 자, 타임아웃 사례를 조금 더 자세히 보겠습니다. 자, PG에서는 이미 성인이 끝났어요. 그런데 우리 서브에이 결과가 아직 안 온 거죠. 그런데 만료 시간은 지났어요. 좌석은 회수가 됐습니다. 다른 사용자가이 좌석을 다시 선점을 한 거죠. 자, 앞서와 같이 중복 판매가 될 수 있는 거죠. 자, 동시 선전만 막았다고 해서 중복 판매 문제가 끝난게 아니죠. 만료 시간보다 승인이 늦게 오거나 혹은 타임아웃 때문에 아예 오지 않거나 이런 상황에서도 중복 판매가 될 수 있는 거죠. 자,이 문제는이 판정하는 양쪽이 서로의 상태를 모르기 때문이라고 했는데요. 자, 그러면 상태를 서로 알게 만들면 되겠죠. 자, 그래서 상태를 하나 더 두겠습니다. 페이먼트 펜딩 상태입니다. 헬드 상태에서 페이먼트 펜딩 상태로 변경되는 것이죠. 자, 사용자가 좌석을 선점하고 난 뒤에이 만료 시간 이전에 펜딩 페이먼트 펜딩 상태로 변경할 수 있습니다.

자, 이렇게 중간 과정을 둔다고 했을 때 헬드 상태에서 아직 페이먼트 팬딩 상태로 넘어가지 않고 만류가 된 거면 즉 피지 자체를 호출하지 않은 것이기 때문에 바로 회수해 버리면 되죠. 반면에 헬드 상태에서 우리가 추가한 페이먼트 팬딩 상태로 변경이 됐다 그러면 앞서 그 만료 회수하는이 스테이트값 헬드 체크하는 데서 조건이 걸리지 않기 때문에 만료가 되더라도 회수가 되지 않겠죠. 즉 헬드 만료 시간이 되어서도이 횟수를해도 되는 상태하고 횟수하면 안 되는 상태가 구분된 거죠.이 이 헬드 상태에서는 아직 결제를 시작하지 않은 것이기 때문에 만료가 되면 회수를 해 버리면 되죠. 반면에 페이먼트 팬딩 상태로 전가 됐다 그러면 결제 요청이 시작된 것이기 때문에 만료가 되어도 회수 회수하지 않고 어 주가 확인을 해야 된다는 거죠. 자 그러면 이번에는이 페이먼트 펜딩 상태 마무리는 또 어떻게 해야 될까요? 다시 말해서 페이먼트 팬딩 상태를 최종 솔더로 바꾸든지 또는 사용 가능한 상태로 바꿔야 될 텐데 그 처리에 대한 얘기입니다.

자, 가장 정상적이고 가장 많이 일어나는 것은 여기겠죠. 페이먼트 펜딩 상태에 전의되고 나서 사용자가 결제를 실제로 다 완료를 하는 거죠. 그래서 피지사로부터 우리 콜백을 받는 거죠. 결제가 성공했다 또는 뭐 거절당했다. 여러 가지 값들이 있겠죠. 우리는 그 결과대로이 좌석의 상태를 솔더로 바꾸든 업웨이 상태로 바꾸든 선택하면 되겠죠. 그런데 예외 케이스가 발생할 수도 있겠죠.이 좌석의 선점 만료 시간이이 한참 지났는데도 계속 페이먼트 팬딩 상태가 되면 어떻게 처리를 해야 될까요? 자, 일반적으로는 우리 PG사는 해당 결제권의 진행 상태를 확인할 수 있는 API를 제공해 주죠. 그래서 어 이런 예외 케이스에서는 한번 조회를 해 보는 겁니다. 그렇게 해서이 결제가 정상적인 상황으로 진행되고 있거나 뭐 성공했거나 실패했거나 상황을 알 수 있으면 그 상태대로 변경을 해 버리면 되는 거죠. 또는이 승인 자체이 결제 자체 시도가 되지 않았고 사용자가이 결제창을 닫고 떠난 경우라고 판단이 된다면 다시 원복시키면 되겠죠.

자, 그래서 일반적으로는 여기 위에 있는요 상황으로 다 마무리가 될 거고요.이 예외 케이스가 생길 수도 있기 때문에 이렇게 피지를 몇 번 조회해 보는 로직을 추가해야 될 수도 있습니다. 보통 이런 예매 시스템에서 가장 큰 리스트는 중복 판매거든요. 두 사람이 동일한 자석을 선택하고 결제까지 성공을 해 버리는 것이 가장 위험하고 CS적으로도 가장 힘든 케이스인 거죠. 누구 거를 회수해야 되는지 이것은 고객 불만으로 이어질 수 있는 거죠. 그래서 페이먼트 팬딩 상태를 확실지도 않은데 판매 가능한 상태로 바꾸는 것보다는 조금 보수적으로 결제 성공이 확실하지 않더라도 조금 더 잡아두는게 비즈니스적으로는 더 안전할 수 있습니다. 자, 이렇게 해서 어 좌석 선점과이 만료 처리에 대해서 설계를 좀 해 봤는데요. 뭐 이것은 딱 정답이 정해진 건 아닙니다.이 규모나 특성에 따라서 설계는 얼마든지 달라질 수 있습니다. 예를 들어서 좌석과 예약을 분리를 할 수도 있겠죠. 모델 자체를. 그래서 좌석은 해당 좌석의 어떤 선전 여부만 알 수 있도록 하고 구체적으로 예약 상황은이 레저베이션이라는 모델로 분리할 수도 있고요.

또는 앞서 봤던 인터파크 사례처럼 다섯 개 선점 단계하고 다음에 결제 단계를 분리를 하고 또는 결제 단계도 조금 더 세분화해서 분리해서 각각의 만료 시간을 또 둘 수도 있습니다. 자, 그런데 어떤 걸 선택하는지는 저는 이제 이런 관 이런 기준을 가져야 된다고 봅니다. 자, 해당 비즈니스의 핵심적인 리스크가 무엇인지 자, 이런 상황에서는 예매 시스템에서는 중복 판매되는게 가장 리스크가 크겠죠. 고객 불만이 엄청날 거잖아요. 좌석이 실제 결제 완료까지 되지 않았는데 팬딩 상태로 남아 있는 것은 회사 입장에서는 조금 손해 수 있지만 고객 불만으로 이어지지는 않겠죠. 그래서이 설계를 결정할 때도 우리 비즈니스에서 어떤게 가장 문제가 될지를 보고 그것을 해소할 수 있는 가장 단순한 구조로 시작을 하고 어 필요해지고이 시스템이 규모가 늘어나고 복잡성이 증가할 때는 이런 뭐 단계를 나누든 테이블을 나누든 요런 거를 적용하면 좋겠습니다. 자, 이렇게 정리를 하고요. 자, 마지막으로 어, 생각해야 될 점 두 가지 말씀드리겠습니다.

자, 앞서 우리 선점 시간을 7분이라고 했죠? 자,이 선점 시간을 어떻게 결정할지도 정해진 답이 있는 것은 아니고요. 자, 길게 잡으면 안전한 판매가 되겠죠. 사용자가 결제하다가 뭐 어떻게 좀 실수하거나 잘못돼도 선점을 오랫동안 잡고 있기 때문에 그 사람이 안전하게 완료할 때까지 조금 보장을 해 주는 거고요. 반면에 짧게 잡으면 뭐 일종 회전율이라고 할까요? 중간에 사용자가 떠났거나 뭐 실수로 잘 못 하는 경우 그냥 튕겨 버리고 다른 사람에게이 좌석을 주는 거죠. 우리 그 기차표 외면은 3분이죠. 3분 3분 동안 예약하지 않거나 혹은 딴 일 하고 있으면 바로 튕겨내 버리죠. 자기가 선착순으로 왔다고 하더라도. 자, 그리고 또 하나는이 결제 같은 경우이 결과가 불명확할 때가 있죠. 그래서 앞서 뭐 피지사를 제시도 조회해 봐야 된다고 했는데요. 이렇게이 결과를 확실하게 확인할 때까지이 만료를 보류하면 역시 안전한 판매가 되겠죠. 그렇지만 어 명확하지 않을 때는 일단 풀어 버리고 다른 사람한테 기회를 주고 어 혹시나 결제가 완료되면 환불로 정리할 수도 있겠죠.

자, 그렇지만 저 같은 경우에는 뭐 이것은 앞서 말씀드린 대로 예매 시스템에서는 아주 리스크가 큰 거일 수 있기 때문에 요거 선택을 하지 않을 것 같습니다. 어쨌든 뭐 정답이 있는 것은 아니고 어 서비스에서 어떤 것을 더 중요하게 생각할지에 따라서 달라질 수 있습니다. 자, 마무리하겠습니다. 결제하는 동안 좌석을 잡아준다. 자,이 도메인의 문제는 동시성 제어와 상태 모델 만료 판정에 대한 설계 그리고 레이스 컨디션, 타임아웃, 몇등성 같은 키워드들하고 연관이 있고요. 자, 이것은 예매 시스템 좌석만의 문제는 아니죠. 대고, 회실, 주차면 선점, 한정판 상품 선점 이런 한정된 자원을 잠시 동안 잡아두는 모든 비즈니스, 모든 도인에서 같은 문제가일 수 있는 거죠. 자, 그래서 이런 문제들에서 오늘이 설계 접근법을 참고하셔서 설계에 도움이 됐으면 좋겠네요. 제 채널에서는 아키텍트를 위한 멤버십을 운영하고 있습니다. 소프트웨어 아키텍처의 정통 이론부터 실무 설계, 프로젝트 관리와 리더십 등 아키텍트로 성장하는데 도움이 될 만한 다양한 콘텐츠를 제공하고 있습니다.

[음악] AI 시대에는 단순 구현을 넘어서 시스템 전체를 조망하고 판단하는 [음악] 역향이 더욱 중요해지고 있습니다. 개발에 머무르지 않고 아키텍트로 한 단계 더 성장하고 싶다면 멤버십에서 저와 함께 공부하고 성장해 보시기 바랍니다. 그리고 지금까지 함께 해 주시는 우리 멤버 여러분 늘 감사드립니다. 함께 성장하는 멤버십이 될 수 있도록 계속 고민하겠습니다. 감사합니다.