Цікаво, але «такое».
Тобто у вас один із сервісів знаходився у постійному циклі народження-смерті не встигаючи навіть працювати, але ви цього не помічали поки меседж брокер не всрався )

35.Скільки буде 7% від 4500?

а на кого розраховане дане питання?

якщо є нормальні дизайн документи

Нормальна документація це вже продовження історії.
А то ж в білбшості випадків в компаінї немає людей які в принципі мають голову на плечах і здатні в дизайн, куди там до документів.

Для того щоб воно так працювало потрібна нереально висока ІТ-культура в компанії яка паблішить файли в папку.
На практиці це трешак.

Дякую за статтю!
Толкові технічні статті по джаві (а не «як зробити хеловорлд на спрінг») нині рідкість на доу.

З вашої статті виходить що СТО це на 98% менеджер, керувальник ризиками і рішатєль конфліктів.
Можливо, у мене трохи викривлене уявлення, але в моїй практиці (я бачив більше продуктових СТО) це в першу чергу людина, на плечі якої лягає вся інфраструктура, цілком і повністю. СТО це той, хто вирішує найстрашніші технічні проблеми, коли армія девопсів підняла лапки і пішла в запой. Тобто найбородатіший старожил у найпрокуренішому найстарішому светрі. І тільки потім, десь там, на 12-му місці він оце все комунікації та інший піпл-менеджмент.
Фактично з вашого опису СТО це тім- (навіть не тех-) лід на максималках.

Упоротий список любителів бродилок.
Тільки кілька стратегій, і немає варкрафту. Немає дьябли.
Хуuня кароче повна

У тебе уявлення про бекенд курільщіка. Бекенд != повна самоізоляція від бізнес-процесу та комунікацій за стіною джири.

Плюсую, обсолютна більшість дупля не ріже як правильно юзать локи. З реактивщиною та сама срака.
Люди роблять Моно.бла().бла().бла() тільки для того щоб одразу зробить .блок() і чекати результат.
Особисто викорчовував таку срань з одного проекту.

ситуацію, коли в одній конторі на кожному ревью знаходились причини не підняти зарплату

Вміти не сидіти в гівноконторах по багато років, жаліючись на злу судьбінушку — це також скіл сіньора.
Тому якщо така ситуація є, а реакції посилання в жопу і переходу в іншу компанію нема, то це також ознака того що кадр не сіньор.

фронтенд слабый

мало общаюсь с клиентом

слабый английский

...

меня уже достало саморазвиваться

Ну тобто ти по цілком об«єктивним критеріям не дотягуєш до певного рівня, але тебе вже задовбало тягнутись?

Сіньор це не ачівка «ви накопичили Х жопогодин, сіньор левел анлокед»

Як об’єктивні

І знову ж не буде ніяких пруфів, я вгадав?

У нас в 2020-2021 теж всі розповідали що продуктивність не знизилася

Пруф або ну ти сам знаєш.

і всіх же потихоньку випирають назад до офісів

Якщо конкретно тебе випирають це не означає шо випирають всіх )

Нижче вже сказали, що це пов«язане не з продуктивністю, а з тим, що каста менеджерів хоче повернуть «good old days» коли вони були «цар во дворца». Важко бути цар-во-дворца якщо підлеглі виконують задачі віддалено і клали болт на твій нагляд.

В одной конторе арендовавшей две комнаты в админздании какого-то завода на выдубичах

Лаконічний та глибокий опис приблизно десь половини укробізнесу розливу нульових :)

сокращать все переменные до 2-3 букв

Це сука біль.

Ну да, все вірно.
А тут до тебе приходить такий д«Арнтаньян і каже «я ***енний спец але не помню шо робив рік тому».
Його в принципі можна найняти і платить якісь рандомні копійки, а на пред"яви казать "слухай чувак, ти думаєш я пам"ятаю суму на яку ми домовились? Вже місяць пройшов!"

Я не запам‘ятовую такі речі ... вирішувалось тімою на якомусь одному часовому колі 2-3 роки тому і більше ніхто за це не згадував

Ну тобто ти хочеш сказати, що можеш напідаліть якесь рішення, а потім такий «я вапше хз шо там як, вже рік пройшов, відваліть». Це такі собі якості. Я б точно такого кандидата не взяв.

Де ви берете такого роду інформацію? Вона із покоління в покоління передається, чи є якась must have література по БД та системному дизайну?

Це комплексне питання.

В ідеалі, це мали б викладати в університеті на технічних спеціальностях. Але в Україні системна криза з освітою, в т.ч. з технічною.
Крім того, я світчер-самоучка, що в універі вчився гуманітарщині, тому до цих речей доповзав сам, через досвід. Але не виключаю, а скоріш впевнений, що вся ця мудрість давно викладена десь в старих товстезних книгах. Які я нажаль не читав )
А досвід складається з багатьох джерел. Це і твої власні помилки, і помилки колег, настанови, коментарі, срачі, холівари в інторнетах і т.д.

Але все це спирається також на тренування внутрішнього відчуття систематизації і порядку. Чого набувають не всі і це не вичитаєш в книзі.

Але щодо книг, то оця хороша, хоч і не безпосередньо по БД, але поряд:
books.google.com.ua/...​hl=uk#v=onepage&q&f=false

а повідомлень не 300 а 3000, то

...нічого не станеться. Про це треба думати якщо повідомлень буде, ну скажім, 30 000 000.

TABLE users (id, .....)
TABLE messages (id, ....)
TABLE message_to_user(
      id, user_id, message_id, time, 
      FK(user_id) REFERENCES users(id),
      FK(message_id) REFERENCES messages(id))

— у таблиці users додати поле wished_at для оновлення часу останнього відправлення повідомлення

Оце помилка дизайну. Час останнього показу повідомлення — це час настання останнього історичного факту показу повідомлення з-поміж багатьох таких історичних фактів.

SELECT TOP 1 time
FROM message_to_user
WHERE user_id = ?
ORDER BY time DESC

— під час кожного запиту додасться перевірка поля wished_at та порівняння його з поточною датою, що якось тупо

Да, тупо. Бо це поле 1) не має існувати 2) не потрібно для логіки

це також таке собі рішення, не подобається

Це єдине вірне рішення, якщо ти хочеш мати рішення в рамках реляційної БД.
Інші рішення автоматично переходять в ранг дивних і шкідливих велосипедів, бо будуть порушувати філософію реляційної БД і не будуть найпростішим і найочевиднішим рішенням. Щоб показати користувачу повідомлення, якого він ще не бачив, достатньо:

SELECT TOP 1 
FROM messages
WHERE id NOT IN (
     SELECT message_id
     FROM message_to_user
     WHERE user_id = ?
     )

Якщо ти НЕ хочеш робити це на реляційній БД — то вся тема нерелевантна.

Хочу розібратися з проектуванням БД під різні задачі, от вигадую собі невелики завдання, та намагаюся їх обміркувати.

Твоя проблема зараз в тому, що ти дізнався про існування БД але ще не зрозумів їхньої філософії, тому ти просто якось розташовуєш дані в базі і не можеш оцінити наскільки вони добре розкладені.
Намагайся спроектувати БД так, щоб кожна таблиця зберігала щось 1 з 3:
— сутність, мутабельна, незалежна від інших сутностей, не містить посилань на інші сутності, не містить даних, що походять від інших сутностей або подій;
— перелік історичних фактів (подій), імутабельні, можуть посилатися на інші сутності;
— зв"язки між сутностями або історичними фактами (джойн таблиці по суті), імутабельні, можуть посилатися на інші сутності

Я вважаю що будувати архітектуру цією революційної ідеї треба на Машині Кузьміна.