d'Ivan

микросервисы - это для горизонтального масштабирования.
то есть когда при увеличении нагрузки - вы увеличивайте количество серверов.

ну а теперь подумайте, что будет с вашей базой данных, когда серверов с микросервисами у вас будет много, скажем 1000, а БД будет одна-единственная?

будет затык, то есть весь смысл горизонтального масштабирования теряется.

для микросервисов целесообразно использовать - своя БД для каждого.
а в качестве единой связующей между ними - использовать MQ.

Но вот возникает ситуация в которой нужно получить запись из базы по опеределенным притериям и тут мы сели в лужу, все эти данные в разных базах в разных сервисах, и нам приходиться их агрегировать через прослойки, вместо обычного JOIN QUERY в базу, мы что-то делаем не так или это издержки микросервисной архитектуры?

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

Базы не стоит хранить на SSD.
Их стоит держать на SSD - для скорости работы - и почаще бэкапить хотя бы на HDD, если вам дороги данные и рассудок.

Нет, там уже используется пул соединений.

Можно указать количество ожидающих (IDLE) соединений db.SetMaxIdleConns и максимальное количество одновременно открытых соединений через db.SetMaxOpenConns

Vscale, reg.ru из самых нормальных, yandex, mail.ru
На счёт ФЗ-152 поинтересуйся с юристами, бывает просто не нужно ничего делать и переносить в Россию не придется

Отвечу по документации...

1. Формат.
Для вас лучше это делать в plain text, т.к. даже будучи в консоли, вы всегда сможете их прочитать.
Форматы: любой из .md, .rst, asciidoc (т.к. есть возможость визуализировать из в pretty format) внутри различных систем.

2. Хранение
Способ хранения - только SCM (какой именно: git, svn, hg или более старое - не знаю, что вы используете). Поясню, почему не файловая система:
- вам важно знать state вашего оборудования на определенный момент. Т.е. вы всегда можете посмотреть конфигурацию, актуальную месяц/два назад и выявить проблемы.
- вы всегда можете сделать diff и посмотреть изменения. Часто, это должно быть сделано не просто сейчас, а "внезапно" :)

Использовать atlassian confluence, как говорят выше, я для ваших задач НАСТОЯТЕЛЬНО НЕ рекомендую. Причина:
- вы привязаны к вендору (даже за 10 баксов за мин. лицензию). Если вы откажетесь от вендора вы НЕ сможете выцепить ее - только copy/paste или покупкой плагинов за сотни баксов.
- у атлассиана разметка жестко забита в софт. Там нельзя выгрузить wiki разметку (кроме как при покупке плагинов за сотни баксов, например, scroll)
- и, самое главное, вам не просмотреть текст в консоли!

3. Визуализация
Здесь все зависит от количества времени, которое вы готовы потратить. Знаю, существуют решения для визуализации md для обычный wiki. Здесь вам лучше погуглить оптимальный вариант для предыдущих двух пунктов.

Если сильно обощать ддосы бывают двух видов -
1 атака на канал вам просто забивают трафиком под завязку сетевой интерфейс вашего сервера и он не может общатся с клиентами, это на стороне самого сервера никак не решается - только внешние решения типа клаудфлары.
2 атака на приложение и сопутствующий софт, заваливают медленными коннтектами вебсервер пока не заокнчится лимит, ищут тяжолые дейсвия с базой на вашем сайте(поиск например) чтобы потом кучей запросов нагрузить базу и сервис начнет тупить, и так далее. Основные приемы борьбы - знать паттерн обычного пользвателя, и настроить необходимые лимиты чуть выше чем надо обычному юзеру) в фаерволе или фронтенд проксе (например haproxy)

не нужны здесь регулярки – достаточно like. типа Articles.where('label LIKE ?', '%Not Started%')

У меня BT400. Работает с AirPods отлично, как в винде так и в хакинтоше. Никаких прерываний или переключений режимов не замечено, стены пробивает на ура. Правда в винде иногда проблемы при переключении с iPhone, но если уж подключилось, работает без проблем. Возможно проблема в самих AirPods?

items: id, title
variations: id, item_id, title, price

понятнее всегда лучше, тк это позволяет в дальнейшем развивать код, у которого ВСЕГДА короткий жизненный цикл, тоесть вы его будете не один раз переделывать и переписывать, и в рамках этого понятность предпочтительней чем сиюминутная "эффективность" которая в длительной перспективы никогда не эффективна.

В принципе при таких ситуациях автоматика должна обесточивать линию.
Но сами понимаете, бывает по разному, возможно кто-то отключил автоматику или она неисправна.
По этому
1. Без паники, ничего особенно страшного не произошло.
2. Близко не подходить и своими силами не пытаться убирать лежачее дерево или провода.
3. Позвонить в МЧС и сообщить о ситуации, возможно они ещё не в курсе и им это не интересно, но они будут вынуждены зафиксировать звонок и предпринять какие-то действия.

Не трогай ни в коем случае!
И даже не подходи близко!
Есть понятие "шаговое напряжение" - убьёт за несколько метров от дерева!
Ликбез: https://ru.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B3%D...

Нет, высшая не нужна. Обычная геометрия пригодится при работе с картами. А так в абсолютном большинстве школьного уровня более чем достаточно, главное чтобы логика хорошо работала.