Нужно это делать так чтобы можно было потом по датам фильтровать)
И определять unique пользователей

Домашний Google analytics пилим?

думаю насколько упрощённую версию можно впилить)

Потом заходят новые требования. Монстр растет. Трогать со временем его уже не хочется, больно, много регресии. Заказчик уже не может эти постоянные баги терпеть. Возвращаемся к отдельным полноценным внешним продуктам.

Угу, так и написал :) Спасибо

Ну это пессимистический взягляд. Есть и противополжный)
Мы верим в свой скил, чётко ограничеваем требуемую ф-циональность и нам не требуется монстр с миллиардом ф-ций(как GA).

дешевый и сердитый вариант - elastic search + kibana

Прочитай я это 5 лет назад, я бы скорее всего не был впечатлен. Но сейчас каждая строчка этой книги находит соответствие в моем опыте. Это невероятно. Ещё более невероятно то, что с момента издания этой книги прошло 20 лет, а примеры актуальны будто книга издана вчера.

Где хранить данные статического сайта с поиском, условно для чата с историей всех сообщений. При условии что может быть скажем 1к юзеров онлайн? Я вот думаю, на сколько возможно сделать такое бесплатно, условный гугл драйв дает лярд запросов в день, что маловато.

А при чём количество пользователей онлайн к способу хранения? Учитывая, что данных будет много, я бы для поиска выбрал elastic search поверх любой базы, в которой бы эти сообщения хранились бы

Приветствую. Подскажите, пожалуйста. Является ли soft deleted мастхэв или это наоборот плохая практика и надо стараться избегать, где не надо?

Кейс: есть товар, категори товаров, юзеры, город,  заказы. Так или иначе все переплетено идетификаторами в один большой клубок. Т.е. у пользователя должен быть город, у товара категория, у заказа товар и пользователь.  
Например нужно удалить товар, но это сделать нельзя, так как придется удалять заказ, ведь заказ не может быть без товара. Либо заказ потеряет информацию, если мы обнулим у него товар.
Если удалим пользователя, то надо удалять заказ - тоже самое, потеря информации.
Чтобы удалить категорию товаров - надо или делать невалидным товар (без категории) или делать мягкое удаление товара, потом мягкое удаление категории.

И вот выходит soft delete должно быть везде в данном кейсе?

Уверены, что это удаление, а не архивация или снятие с витрины? Или окончание остатка

Возможно терминология выбрана неверно. Но тут речь же идет еще и о пользоватлях и о городе и о категории товаров.

Ну в реальности города все таки не удаляются. Категории — вообще сомнительно для софтделита

Все кейсы разные.
Если у товара цена изменилась, созданный ранее заказ не должен меняться. Если пользователя надо удалить, то gdpr требует полного удаления всей его информации, без всяких софтов. Заказ в принципе нелогично удалять - как потом баланс в конце года подбивать по деньгам на удалённые заказы?.. и т д - каждый случай - отдельный

во-первых: не обязательно все удалять каскадом, можно запретить удаление, если есть релейшны, навесить валидаций и просить пользователя разобраться с товарами перед тем как удалять категорию
во-вторых: есть всякие gdpr и тебе может быть просто нельзя софт делит
в-третьих: в заказе не обязательно хранить ссылку на товар, можно просто копию нужных полей

Ну если я удалю категорию, мне надо либо удалять все товары, либо делать их невалидными (без категории) - а это повлияет на информацию в заказе.

Решение по поводу дублирования информации в сам заказ - в принципе это решает.

Ну я в целом валидацию сначало и поставил, чтобы не было каскада. А вот что делать потом - софт или хард, у меня возник вопрос.

Как я понял, в таких случая надо подумать об излишнем  каплинге и добавить избыточности информации.

Странно удалять товары из-за удаления категории, очень странно

Т.е. сделать возможность товару быть без категории?