[STEP 1-3] url-shortener 기능 정의

[MyLittleChicken]

안녕하세요 왓에버 기획자님!
현재 운영중인 url-shortener 서비스의 기능들에 대해
질문드릴 점이 있어 PR 드립니다.
부담 갖지 마시고 편하게 해주세요😊

🧑‍💻질문 사항

1. url 단축 기능

• 단축된 url 은 몇 자가 적당할까요?
  • 7자리 에서 9자리 사이면 어떨까요? ref.밀러의 매직 넘버 7
• 단축된 url 은 고유해야 할까요?
• 단축된 url 은 영구적으로 보관되어야 할까요?

[Hyune-c]

• 단축된 url 은 몇 자가 적당할까요?
  • 7자리 에서 9자리 사이면 어떨까요? ref.밀러의 매직 넘버 7

기획자) 네 좋다고 생각해요. (사실 별 생각 없음)

• 단축된 url 은 고유해야 할까요?

기획자) 네. 그래야되지 않을까요?

• 단축된 url 은 영구적으로 보관되어야 할까요?

기획자) 그랬으면 좋겠어요. 나중에 과금안에 따른 보관 기간 차등을 만들건데, 영구 보관도 플랜에 넣을 것 같아요.

[MyLittleChicken]

다음과 같은 내용을 고려했습니다.

• base62 를 통해 encode 하는 경우 최대 약 3.5조(62^7) 까지의 숫자를 7자리의 문자로 표현 가능합니다.
• epoch time (ms) 를 통해 key 를 생성하는 경우 약 2081년 까지 7자리의 문자로 표현 가능합니다.
• ms 를 사용하므로 중복 제거를 통해 초당 최대 1000개의 고유한 key 생성이 가능할 것으로 예상됩니다.

[Hyune-c]

base62 를 통해 hashing 하는 경우 최대 약 3.5조(62^7) 까지의 숫자를 7자리의 문자로 표현 가능합니다.

• encode vs hash vs encrypt

ms 변환을 통해 초당 최대 1000개의 고유한 key 생성이 가능할 것으로 예상됩니다.

• 채번 시점 1천개 vs 중복 제거 후 1천개

[MyLittleChicken]

encode vs hash vs encrypt

• 용어의 혼동이 있었습니다. 정확하게는 encode 가 맞는 표현입니다.
• encode 는 암호화 시 key 가 필요하지 않으며 복호화 를 통해 원래 형태로 되돌릴 수 있습니다. (양방향)
• hash 는 마찬가지로 암호화 시 key 가 필요하지 않으며, encode 와 다르게 원래 형태로 되돌릴 수 없습니다. (단방향)
• encrypt 는 암호화 시 적절한 key 를 필요로 하며, key 를 이용하여 원래 형태로 되돌릴 수 있습니다. (양방향)
• ref Encryption vs Encoding vs Hashing

채번 시점 1천개 vs 중복 제거 후 1천개

• 채번 시점에서는 1000개를 초과할 수 있습니다.
• 고유한 key 생성이라는 단서를 놓고 봤을 때 충분히 의미가 전달될 수 있다고 생각했습니다.
• 다만 중복 제거 후 1000개가 더 명확한 표현임은 확실합니다.

---

피드백 주신 내용 두건 모두 반영하여 수정 진행하겠습니다.
감사합니다.

[Hyune-c]

base62 를 통해 hashing 하는 경우 최대 약 3.5조(62^7) 까지의 숫자를 7자리의 문자로 표현 가능합니다.

• encode vs hash vs encrypt

ms 변환을 통해 초당 최대 1000개의 고유한 key 생성이 가능할 것으로 예상됩니다.

• 채번 시점 1천개 vs 중복 제거 후 1천개