valexeich

Говорю сразу мьютекс мне не подходит, так как это уже не будет параллельно.

С чего бы "уже не будет параллельно" ? Очень даже будет. По факту, при параллельных операциях всегда будет какая-нибудь блокировка, даже в Wait-Free алгоритмах, где используется CAS она есть, только на машинном уровне.

Как можно реализовать такое поведение?

Если не хочешь мьютекс (или другой блокирующий примитив), то используй CAS (Compare And Swap). Вот документация

Идея слудующая:
- хранишь где нибудь поле с этим прокси
- при начале каждой операции сохраняешь старое значение прокси
- когда получаешь 429, то CAS'ом меняешь, то что хранится на новое (сравниваешь со старым)

v-model="selected[index]"

Ненормальная. HTTP-клиенты, включая бразуер, рассчитывают на идемпотентность GET-запросов, а потому могут выполнить его без спросу или повторить произвольное количество раз. Так что не удивляейтесь, если после захода на страницу с комментариями произойдёт их удаление, хотя вы ничего не нажимали.

С точки зрения БД, просто связная таблица или несколько. Это же классическое отношение "многие ко многим".
Есть таблица "Пользователи" с каким-то первичным ключом.
Есть таблица "Аниме" с каким-то первичным ключом.
Если делаешь отдельную связную таблицу на каждый тип списка (т.е. одна для "просмотрел" и одна для "буду смотреть"), то они будут иметь вид "ID пользователя, ID аниме", и эти же два поля будут составным первичным ключом. Наличие строки в таблице будет означать, что указанный пользователь внёс указанное аниме в список, соответствующий таблице.

Либо можно сделать общую таблицу "Списки", тогда её вид будет немного иным - "ID пользователя, ID аниме, Тип списка". Если пользователь может поместить одно аниме только в один список, то ключ будет как выше, а если в несколько одновременно, то ключ будет все три поля.

А уж как это сделать с точки зрения моделей, читай документацию. Это одна из самых базовых вещей, если что.