Vladislav Orlov

Как понять микросервисы?

Прочитать соответствующую книгу (а лучше ещё парочку про DDD или хотя бы посмотреть этот доклад)

Затем ответить на несколько вопросов:
1. Почему вы решили, что микросервисы что-то вам дадут?
2. Есть ли у вас настоящие причины для микросервисной архитектуры? (А именно: зоопарк технологий с невозможностью написать 99% на одном языке; более тысячи разработчиков; сложность выкатки монолита в виде часов прогонов CI/CD — тестов, билда, деплоя, стопоров выкатки в виде кучи проблем из-за разработчиков; вы такие же большие как гугл, убер, амазон и т.п.). Или вам просто нравится модное слово "микросервисы"?

Не получится создать хорошую микросервисную архитектуру без умения создать хороший модульный монолит. В этом случае вы получите не только все проблемы плохого монолита: высокая связанность, каскадные падения, долгий CI/CD; но и все проблемы микросервисов: их надо оркестрировать (у вас же есть команда, которая будет поддерживать инфраструктуру?); каждому микросервису нужно своё CI/CD (и хорошее); сеть может (и будет) лагать и обрываться; длительность запросов увеличится на порядок(ки) (особенно если выбрать какой-нибудь JSON-RPC over HTTP); нужно предусмотреть failover strategy (например, идемпотентные ретраи. Вы же уже знаете про correlation id, саги и что делать, если прилетел network error на запрос в другой сервис "списать 10 баксов"?) и circuit breakers; трейсы и логи, которые не пришлось бы искать по сотням .log файлов от каждого сервиса; бизнес-логика расползётся по разным микросервисам и нарушит SRP (пофиг, что нарушит, важнее то, что это починить будет сильно сложнее). Список можно продолжать долго.

Важные файлы на яндекс-диске.
Рабочие проекты на гитхабе/гитлабе.
А саму систему нафига бэкапить? Она у меня на днях в первый раз за 8 лет рухнула. Ну накатил по новой и фиг с ней.

Точно так же как и в другой канал/группу/чат - по ID

1. кэш
2. синглтон
3. тупо статическая переменная в классе.

select t1.id,
       t1.model,
       t2.category,
       t2.main_category
  from table1 t1
       left join table2 t2 on t2.id = t1.id
 where t2.main_category = 1

JS фреймворки уже несколько лет - это будни фронтэнда, и это не мода, и это никуда не уйдет. Также как никуда не уйдет традиционная верстка. Они будут жить вместе. Четкую границу между веб-сайтами и веб-приложениями провести нельзя, но суть вопроса автора вопроса понятна.

Конечно же, делать простой лендинг на чем-то типа Angular/React - это клиника. Хотя если нужны интерактивные блоки, очевидно лучше использовать Vue, чем городить что-то на jQuery. Vue как раз хорош тем, что его можно задействовать только для отдельных виджетов, а весь остальной сайт продолжай писать как тебе угодно.

Сам Vue фреймворк и свой код Vue-виджетов нет необходимости всегда собирать. Шаблоны для Vue не похожи на кошмар, приведенный в листинге. Все верстать кастомными тегами не обязательно, по мне, так это тоже клиника. Да, в продуктив все равно придется собирать, и сборка всегда сложная, и это якорь, который еще несколько лет придется тащить, но со временем втягиваешься, скрипт сборки кочует из проекта в проект. Со сборкой придется потерпеть.

Короче, если вы верстаете но на JavaScript ничего сложней jQuery вы не умеете, то вы в заднице. И каждый год вы все глубже.

за вас гуглить никто не будет, есть много примеров уже

Ваша идея полный бред. В таблице должна хранится информация, а не дефолтные значения. Так как вы написали у вас буду заполнятся 5 колонок уникальными данными, id подозреваю в их числе (если нет добавьте) и все это ваша главная таблица. Все остальное нужно хранить в другой таблице которая сказывается с главной по foreign key.

Пример названий колонок второй таблицы:
- ид из основной таблицы
- дата записи
- запись

По такой системе проблем с работой не будет, так как вы с лёгкостью можете получить любую требуемую информацию одним запросом