앞 단계에서 사람마다 채널마다 마지막 읽은 번호를 두었습니다. 읽음 표시는 그 번호를 상대에게 보여주는 기능입니다. 새 저장소가 필요하지 않습니다.
그런데 이 기능은 조용히 시스템에서 가장 무거운 쓰기가 됩니다.
읽음 갱신이 메시지보다 많다
메시지는 보낼 때 한 번 생깁니다. 읽음은 보는 사람마다, 스크롤할 때마다 생깁니다. 채널에 12명이 있으면 메시지 한 건에 읽음 갱신 12건이 따라옵니다.
| 항목 | 하루 |
|---|---|
| 메시지 쓰기 | 2억 건 |
| 읽음 갱신 | 그보다 몇 배 |
그래서 갱신 횟수를 줄이는 것이 이 기능의 핵심 설계입니다.
읽은 번호는 늘 커집니다. 44에서 52까지 올라가는 동안의 중간 값은 아무 의미가 없습니다. 클라이언트가 1초쯤 모아서 마지막 번호만 보내면 결과가 같습니다.
뒤로 가지 않게 만든다
재시도나 순서 뒤바뀜으로 작은 번호가 늦게 도착할 수 있습니다. 그때 그대로 덮으면 읽음 표시가 거꾸로 갑니다.
지금 저장된 번호보다 큰 값만 받는다
작은 값은 조용히 버린다
이 규칙 하나로 같은 요청을 여러 번 보내도 안전해집니다. 번호가 늘 커진다는 성질이 재시도를 안전하게 만들어 줍니다.
채널이 커지면 기능을 줄인다
읽음 표시의 비용은 채널 크기에 따라 제곱으로 늘어납니다. {REQ['max_channel']} 채널에서 각자 읽으면 갱신 {REQ['max_channel']} 건이 생기고, 그것을 전원에게 알리면 전달이 25억 건이 됩니다.
| 채널 크기 | 보여주는 것 |
|---|---|
| 1대1 | 읽음과 안 읽음을 정확히 |
| 평균 {REQ['avg_channel']} 수준 | 읽은 사람 수, 또는 누가 읽었는지 목록 |
| 아주 큰 채널 | 표시하지 않는다 |
기능을 줄이는 것이 최적화보다 먼저입니다. {REQ['max_channel']} 채널에서 누가 읽었는지 아는 것은 사용자에게도 쓸모가 적습니다. 요구사항을 자를 수 있는지 먼저 보고, 자를 수 없을 때 기술로 풉니다.
읽음 전파는 팬아웃을 한 번 더 만든다
읽음 표시를 실시간으로 보여주려면 상대에게도 밀어 줘야 합니다. 이것은 메시지와 별개의 팬아웃입니다. 작은 채널에서는 그대로 밀어 주고, 큰 채널에서는 밀지 않고 화면을 열 때 조회로 가져옵니다.
끄는 사람은 남의 것도 못 본다
읽음 표시를 끄는 설정을 주면, 그 사람은 남의 읽음 표시도 볼 수 없게 만듭니다. 한쪽만 보는 것이 가능하면 설정을 끄는 것이 이득이 되어 모두가 끄게 됩니다.