В этой подборке вопросы сгруппированы по формату «Технические вопросы», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: database, sql, backend.
Абсолютно неуязвимого хранилища в браузере нет. Для web-сессии часто выбирают серверную сессию и cookie с HttpOnly, Secure и подходящим SameSite, уменьшая доступ JavaScript к секрету.
Документация должна объяснять границы системы, сценарии, данные, контракты интеграций, ошибки и эксплуатацию. Достаточность определяется тем, может ли команда безопасно менять и поддерживать систему.
Профили связывают по подтверждённому событию идентификации и явному правилу соответствия. Совпадения IP, устройства или похожих полей сами по себе недостаточно для уверенной склейки.
Нужна явная модель связи анонимного контекста и известного пользователя после входа. Она позволяет строить воронку, но не должна объединять людей по ненадёжным догадкам.
Базовые проверки качества данных включают полноту, уникальность, допустимость значений, ссылочную целостность и свежесть. Конкретные правила должны отражать смысл данных.
Список до 2000 ID может сделать URL слишком длинным для клиента, прокси или сервера. Нужно оценить лимиты цепочки, стоимость запроса и выбрать контракт пакетного поиска.
В DDD Entity обладает идентичностью, сохраняющейся при изменении атрибутов. Обычно она представлена идентификатором, но его форма определяется доменом, а не обязательно автоинкрементом БД.
По HTTP-семантике POST не относится к safe-методам: он может запрашивать изменение состояния. В смысле шифрования и защиты POST не безопаснее автоматически — нужны отдельные меры.
Начинайте с измерений: медленные запросы, планы, блокировки и ресурсы. Затем оптимизируйте запросы, индексы, объём чтения, модель данных и взаимодействие приложения с базой.
Денормализацию делают, чтобы упростить и ускорить частые чтения: заранее объединяют данные или сохраняют агрегаты. Цена — дополнительное хранение и поддержка согласованности копий.
Unhappy flow OTP включает неверный идентификатор, сбой доставки, просроченный или неверный код, лимит попыток, повторную отправку и потерю сети. Ошибки должны быть понятными и не раскрывать существование аккаунта.
Базы различают по модели данных: реляционные, документные, ключ–значение, графовые и другие. Назначение, например временные ряды или поиск, — ещё один независимый способ классификации.