Условно, если прицепить к пользователю и сообщению некую модель уведомлений с полем as_read - кажется нормальным решением, но вопрос оптимизации БД ещё актуален, т.к. если там 1000 уведомлений, то это явная проблема
Использовать Redis
Ну чисто в Celery таски создавать?
Это уже как тебе удобнее в рамках приложения. Но подобные задачи, когда нужно не нагружать БД большим числом операций записи, обычно решаются использованием key-value хранилища
Ну все же как вариант - возможен?
Ну я не про брокер, а про хранилище, в которое ты можешь писать быстрее, чем в SQL-СУБД. Тебя же потенциально большое количество операций записи в единицу времени смущает, полагаю?
Да)
Нормально ли будет генерить id уведомления о сообщении, отталкиваясь от времени записи в БД сообщения или есть какая-нибудь лучшая практика для этого момента?
Уведомления это такая же сущность как и сообщение
Обсуждают сегодня