🥸 서론
현재 진행 중인 Ticketing 프로젝트는 시스템이 분리되어있다는 가정 하에 진행된 프로젝트입니다.
여기서 결제시스템에서는 어떤 유저가 결제했는지에 대한 정보가 있어야 합니다.
처음 설계 당시에는 유저 PK 값을 넣어서 사용하려 했지만, 몇 가지 문제가 있어서 대체 유니크키 생성을 결정하게 되었고,
그 내용을 정리해보려 합니다.
😎 본론
기존 ERD 구조입니다.
여기서 Payment 에서 User의 pk 값을 가지고 있죠.
고민의 시작인 API의 간단한 Sequence Diagram 입니다.
여기서 결제 목록 요청을 할 때 각 유저의 고유한 값을 Payment에서 가지고 있어야
유저의 결제 목록을 응답해줄 수 있습니다.
여기서 기존엔 User의 PK를 사용했는데,
왜 고민했는지 Email, Unique Id를 왜 고민했고 어떤 걸 선택했는지 알아봅시다.
🤔 PK를 고민한 이유.
사실 PK를 그냥 사용해도 됩니다.
제일 간편한 방법입니다.
하지만 문제로 생각했던 부분은 PK가 순차적으로 증가하는 값이란 것입니다.
만약, 순차적으로 증가하는 값을 사용된다는 걸 아는 사용자가 UserSystem을 거치지 않고,
PaymentSystem을 바로 결제 목록 요청을 하게 되면 어떻게 될까요??
순차적으로 값을 1, 2, 3, 4, ... 로 늘려보면서 다른 사용자들의 결제 목록을 조회할 수 있게 됩니다.
물론, UserSystem 외의 접근을 막을 수도 있지만
보안을 생각해서 외부에 이렇게 순차적으로 늘려서 접근할 수 있다는 걸 노출되길 원하지 않았습니다.
장점
1. 유니크 값으로 하나밖에 존재하지 않는다.
2. 이미 존재하는 값이고, 현재 이에 맞게 설계 되었기 때문에 변경할 게 없다.
단점
1. 사용자에게 PK가 노출될 경우 악용될 가능성이 있다. (예 - 다른 사용자의 정보 조회)
🤔 Email을 고민한 이유.
사실 Email을 고민했던 이유는, '앗 그냥 Email 쓰면 편할텐데..' 로 시작하고, 끝났습니다.
장점
1. 유니크 값으로 하나밖에 존재하지 않는다.
2. JWT에 존재하는 값으로 Payment로 바로 호출하는 API 개발 시 UserSystem을 호출하지 않아도 된다.
하지만, 단점이 너무 명확해서 사용하지 않기로 하였습니다.
단점
1. Email은 결국 변경이 가능한 사용자의 데이터다.
2. 변경 가능한 값으로 공유하게 되면, 관리하기가 힘들어진다.
😏 그러면 답은 새로운 Unique Key!
사용자가 유추하기 힘든 Unique 값을 새로 추가하여 외부에 노출할 때에는 이 값을 사용하는 방법입니다.
New Unique Key를 사용하면 위에서 알아본 두 가지 방법의 단점을 극복할 수 있습니다.
장점
1. 유저가 유추할 수 없는 유니크 값을 사용한다.
2. 현실세계에 의존하지 않는 값으로 변경 가능성이 없다.
하지만, 이에 따른 단점도 존재합니다.
단점
1. 새로운 컬럼 추가 및 설계 변경..!
하지만, 이런 단점 정도는 아직 개발 단계이기 때문에.. 극.복. 할 수 있습니다 .^^.
그럼 UUID를 사용할까?
저는 UUID가 아닌, 트위치에서 처음 발표한 Snowflake 를 모방한 알고리즘을 사용하였습니다.
UUID를 사용하지 않은 이유
1. 128Bit으로 크기가 크고, 무겁다.
2. 알파벳과 뒤섞인 값보다는 숫자로만 된 값이 좀 더 파악하기가 용이하다고 판단했다.
🫣 결론
항상 선택에 있어서 트레이드오프가 있는 것 같습니다.
여러가지 방법을 생각한 후 현재 상황에 어떤 게 좀 더 우리한테 맞을까를 고민한 후 결정해보았습니다.
저희가 선택한 방법이 무조건적인 정답이라 생각하진 않지만, 설득력이 있는 결정이었으면 좋겠습니다.
피드백은 언제나 환영입니다!
다음에는 메모장에 적어둔 Unique ID 생성하는 방법을 정리해보도록 하겠습니다..
'Project' 카테고리의 다른 글
| [Ticketing] 다른 테이블에 중복 데이터를 추가한 이유 (0) | 2022.07.07 |
|---|---|
| 'Graphql'을 선택한 이유 (0) | 2020.09.01 |
