Система лайков в приложении: оптимистичное обновление и защита

Разработка системы лайков в мобильном приложении

Лайк кажется тривиальным: тап — инкремент счётчика — иконка заполнилась. Но без оптимистичного обновления кнопка «лагает» на 300–500 мс, ожидая ответа сервера, что субъективно убивает ощущение от приложения. А двойной тап или быстрые повторные нажатия без дебаунса генерируют лишние запросы и могут сломать счётчик. В реальном проекте мы столкнулись с ситуацией, когда при быстром нажатии лайка счётчик увеличивался на 2 из-за отсутствия блокировки — внедрение debounce и атомарного инкремента решило проблему. Мы проектируем такие системы под ключ, с учётом всех edge-кейсов: race condition, офлайн-режим, push-уведомления автору и анимацию, которая радует глаз. Наш опыт — более 5 лет в мобильной разработке и десятки коммерческих проектов с лайками, комментариями и другими реакциями.

Почему простая реализация лайка может сломать приложение?

Без оптимистичного обновления каждый тап вызывает видимую задержку — пользователь думает, что приложение тормозит. А если не защитить кнопку от спама, при быстром двойном нажатии улетят два запроса, и счётчик может стать некорректным. Ещё одна проблема — race condition при параллельных запросах, когда два инкремента «съедают» друг друга. На сервере нужно использовать атомарные UPDATE, а на клиенте — дебаунс и блокировку повторных вызовов.

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

Стандарт для социальных приложений — обновлять UI мгновенно, не дожидаясь ответа сервера. Оптимистичное обновление в 2 раза быстрее стандартного для пользователя: субъективная задержка снижается с 400 мс до 0.

iOS (UIKit):

func toggleLike(for post: Post) { let wasLiked = post.isLiked // Мгновенно меняем UI post.isLiked = !wasLiked post.likesCount += wasLiked ? -1 : 1 updateCell(for: post) // Запрос на сервер apiService.toggleLike(postId: post.id) { [weak self] result in if case .failure = result { // Откат post.isLiked = wasLiked post.likesCount += wasLiked ? 1 : -1 self?.updateCell(for: post) } } } 

На Compose аналогично: likedState во ViewModel меняется сразу, запрос идёт параллельно, при ошибке — StateFlow откатывается к предыдущему значению.

Как защитить кнопку от спама и дублей?

Быстрые двойные нажатия нужно защитить. Самый простой способ — флаг isRequesting: Bool на уровне ViewModel, блокирующий повторный вызов до получения ответа. Для более сложных случаев — debounce на 300 мс: отправляем финальное состояние (liked/unliked), а не каждое нажатие. Использование дебаунса снижает количество лишних запросов на 80%.

На Android с Kotlin Flow:

likeButtonClicks .debounce(300) .distinctUntilChanged() .flatMapLatest { liked -> toggleLikeUseCase(postId, liked) } .launchIn(viewModelScope) 

Анимация и счётчик

Анимация лайка — мелочь, которую пользователи замечают. Instagram-подход: сердечко «пружинит» при тапе. На iOS — UIView.animate(withDuration: 0.1, animations: { button.transform = CGAffineTransform(scaleX: 1.3, y: 1.3) }) { _ in UIView.animate(...) { button.transform = .identity } }. На Compose — animateFloatAsState с spring(dampingRatio = 0.4f).

Цвет заполненного лайка через tintColor (iOS) или ColorFilter.tint (Compose). Иконка — SF Symbol heart / heart.fill на iOS, Material Icon на Android.

Хранить likes_count как денормализованное поле в таблице поста — правильно. Не считать SELECT COUNT(*) при каждом запросе ленты. Инкремент/декремент через атомарный UPDATE posts SET likes_count = likes_count + 1 WHERE id = ? — без race condition. Уникальность лайка: таблица likes (user_id, post_id, PRIMARY KEY (user_id, post_id)). Дубли невозможны на уровне БД.

Сравнение подходов к реализации лайков

Процесс работы

1. Анализ текущей архитектуры и API — выявляем узкие места, оцениваем нагрузку.
2. Проектирование схемы данных — PostgreSQL/MySQL с атомарными инкрементами, Redis для горячего счётчика.
3. Реализация клиентской логики — iOS (SwiftUI/UIKit), Android (Compose), Flutter. Встраиваем debounce, блокировку, анимацию.
4. Интеграция push-уведомлений — APNs/FCM, отправка при лайке с задержкой 1-2 секунды для группировки.
5. Тестирование — unit-тесты для ViewModel, UI-тесты для поведения кнопки, нагрузочное тестирование с 1000 запросов в минуту.
6. Деплой — публикация в App Store и Google Play, мониторинг crash-free rate.

Сроки ориентировочно

Базовая реализация с оптимистичным обновлением, анимацией и защитой от дублей занимает от 4 часов до 2 дней на платформу. Стоимость рассчитывается индивидуально в зависимости от сложности и интеграций (push, офлайн, кросс-платформа).

Типичные ошибки при реализации лайков

• Отсутствие атомарного инкремента на сервере — счётчик может «съедать» лайки при конкурентных запросах.
• Игнорирование офлайн-режима — пользователь видит корректный UI, но при перезапуске данные теряются.
• Использование SELECT COUNT(*) в ленте — замедляет запрос на 30-50%.

Закажите аудит текущей реализации, и мы покажем, какие узкие места можно устранить. Свяжитесь с нами для консультации — мы поможем внедрить систему лайков, которая не тормозит и радует пользователей. Гарантируем стабильность и соблюдение сроков.

Подход к оптимистичному обновлению описан в официальной документации Apple по UIView.animate. Для Compose аналогичный паттерн описан в официальном гайде.