Как быстро происходило обновление числа просмотров?

Что проверяют

Это вопрос про ваш реальный проект: был ли у вас счётчик, как он был устроен и понимаете ли вы, откуда бралась задержка. Следом спрашивают про конкурентные обновления, накрутку и что будет при росте трафика в десять раз.

Как отвечать

Отвечайте от своего опыта и называйте реальные цифры: какая была задержка, как вы её измеряли и почему её хватало. Удобный каркас: путь просмотра от события до экрана.

• фиксация события: прямой UPDATE ... SET views = views + 1 в PostgreSQL прост, но на популярной записи запросы встают в очередь за блокировкой строки. В Django это filter(pk=pk).update(views=F("views") + 1), атомарно на стороне базы;
• буфер: INCR в Redis атомарен и выдерживает десятки тысяч операций в секунду, а в базу накопленное сбрасывается пачкой раз в N секунд задачей Celery beat или отдельным воркером. Отставание в базе равно периоду сброса, и это стоит проговорить;
• уникальные просмотры: PFADD и PFCOUNT на HyperLogLog считают уникальных посетителей с погрешностью меньше процента и в крошечной памяти;
• большой поток: события в Kafka, агрегация окнами, хранение в ClickHouse;
• доставка клиенту: обычно счётчику хватает обновления при загрузке страницы или опроса раз в несколько секунд. WebSocket или SSE оправданы, когда живое число это часть продукта, как в стримах.

По форме хороший ответ звучит так: «в базе число отставало на период сброса, на странице обновлялось при перезагрузке, для статистики автора этого хватало, а запись в базу шла пачками». Цифры подставляйте только свои. Если счётчиков вы не делали, так и скажите и расскажите, как устроили бы его и какую задержку сочли бы допустимой.

Где спотыкаются

Инкрементируют в Python: post.views += 1; post.save(). При параллельных запросах часть просмотров теряется, потому что два процесса читают одно и то же значение.

Называют задержку «практически мгновенной» или «меньше 100 мс» без замеров. Следующий вопрос «как мерили?» разваливает такой ответ.

Забывают про потери и накрутку: Redis без персистентности теряет несброшенные просмотры при перезапуске, а боты без дедупликации раздувают счётчик.