クイズ: 注文のライフサイクルと時計

주문 이벤트를 재생할 때 cancel_req 가 상태를 바꾸지 않아야 하는 이유는?

• 취소 요청은 거래소에 도달하지 않을 수도 있어 신뢰할 수 없기 때문에
• 요청을 보낸 것과 취소가 확정된 것은 다른 사실이고, 요청 뒤에 체결이 붙을 수 있기 때문에
• cancel_req 이벤트에는 수량 정보가 없어 상태를 계산할 수 없기 때문에
• 거래소가 cancel_req 를 로그에만 남기고 처리하지 않기 때문에

거래소 시각으로 재생하면 취소, 수신 시각으로 재생하면 체결로 나오는 주문이 40건 있다. 사후 재구성과 분쟁 대응의 근거로 삼아야 할 것은?

• 수신 시각. 우리 시스템이 실제로 그렇게 처리했기 때문에
• 두 시각의 평균. 어느 한쪽에 치우치지 않기 때문에
• 거래소 시각. 시장에서 실제로 일어난 일의 순서이고 규정도 그것을 기준으로 쓰기 때문에
• 애플리케이션 처리 시각. 최종적으로 상태를 확정한 시점이기 때문에

같은 exec_id 를 가진 체결 이벤트가 두 번 들어왔다. 올바른 해석은?

• 거래소 장애 신호이므로 즉시 세션을 끊고 재접속해야 한다
• 체결이 실제로 두 번 일어난 것이므로 수량을 두 번 더해야 한다
• 재전송이나 세션 복구에서 흔히 일어나는 정상 동작이고, 거르는 것은 받는 쪽 책임이다
• 우리 로그 저장 과정의 버그이므로 로그를 다시 받아야 한다

중복 체결을 찾을 때 '누적 체결이 주문 수량을 넘긴 주문' 만 세면 무엇을 놓치는가?

• 부분체결로 끝난 주문에서 부풀었지만 주문 수량을 넘지 않은 건들. 아무 경보도 울리지 않는다
• 정정으로 수량이 늘어난 주문. 초과 판정 기준이 달라진다
• 거부된 주문에 붙은 체결. 상태가 rejected 라 집계에서 빠진다
• 가격이 다른 두 체결. 수량은 같아도 금액이 어긋난다

재생이 끝난 뒤 '누적 체결이 주문 수량 이상이면 상태는 filled' 라는 규칙을 넣는 근거로 가장 적절한 것은?

• 체결이 취소보다 더 자주 일어나므로 통계적으로 유리하기 때문에
• 체결은 되돌릴 수 없는 사실이고 취소는 잔량에만 적용되므로, 잔량이 0이면 취소가 체결을 지울 수 없기 때문에
• 거래소가 체결 이벤트를 취소 이벤트보다 먼저 보내도록 규정하고 있기 때문에
• 상태 필드를 filled 로 두면 정산 배치가 오류를 내지 않기 때문에

OMS 상태 필드와 재구성 결과를 대조했더니 상태가 다른 것이 27건, 체결 수량까지 보면 67건이었다. 이 40건의 차이가 뜻하는 것은?

• 대조 기준일이 달라 생긴 시차이므로 같은 시점으로 맞추면 사라진다
• 재구성 코드의 반올림 오차이므로 허용 오차를 두어야 한다
• 상태 문자열은 우연히 같지만 체결 수량이 빠져 있는 주문들. 상태만 보는 대조로는 영원히 드러나지 않는다
• OMS 가 아직 처리 중인 주문들이므로 조금 뒤에 다시 세면 맞는다

실시간 처리기가 낸 상태와 사후 재구성이 낸 상태가 다를 때 가장 현실적인 운영 방침은?

• 실시간 처리기를 거래소 시각으로 정렬하도록 바꿔 두 결과를 항상 일치시킨다
• 사후 재구성 결과를 정본으로 두고 실시간 결과를 그것으로 보정하는 절차를 만든다
• 두 결과가 다르면 그 주문을 보류 상태로 두고 담당자가 매번 판단한다
• 실시간 결과를 정본으로 두고 사후 재구성은 참고 지표로만 쓴다