Сергей Рогожкин

Сам нахожусь в поисках идеального ответа на ваш вопрос, но кое что есть для размышления по этому поводу:
1. https://github.com/gothinkster/realworld (тут не только Golang)
2. https://github.com/golang-standards/project-layout

Чтобы мокать в модульных тестах, есть вот такое:
https://github.com/posener/wstest

Также есть вариант делать интеграционки/E2E-тесты через
https://github.com/gavv/httpexpect
Запилено тут, юзать через форк (ибо у автора 2 месяц руки не доходят поревьюить).
Там можно тесты натравливать как напрямую на HTTP-сервер с WS, так и подменить клиент чтобы он сразу к хэндлерам присасывался, не подымая полноценный HTTP-сервер (как раз идею и слизал с posener/wstest).

Оба решения используются мной на реальном проекте без проблем и вполне удачно.

Пользуются сторонними сервисами. Если очень большие объемы, то есть смысл использовать https://aws.amazon.com/ses/ разница в цене с тем же mailchimp довольно внушительная.

Ну йопт. Вот вы айтишник. Вы же знаете что вопросы по теме надо задавать тем кто шарит в теме, а не сгружать вопросы по программированию переводчикам. Сходите к врачу! И он вам все скажет что и как лучше для ВАШЕГО организма.

START TRANSACTION;
select * from users where id = 54 FOR UPDATE
//проверка бизнес логики на наличие денег
update `users` set `balance` = `balance` - 150 where `id` = 54;
COMMIT;

Запрос "where `id` = 54 and `balance` >= 150" - опасен.
Innodb лочит не конкретные записи, а диапазоны индексов - при таком запросе в блокировку будут попадать все записи с балансом >= 150, со всеми вытекающими.

Основная решаемая задача - пропитание дизайнера.

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

Внутри foreach используется strcmp, имеющий сложность O(N)

Цикл также имеет такую сложность. Сложности алгоритмов вложенных перемножаются:

O(kN^2 + nlogn)

k - количество внутри алгоритмов со сложностью O(N), так как там strtolower, preg_split и т.д, то, соответственно домножается цикл O(N*(N + N + ... N)) ( в пределах одного блока сложности суммируются )

nlogn - из-за usort, я не знаю какой там алго используется, поэтому возьмем самый быстрый.

В результате округляем до того значения, который дает большой самый вклад, т.к при росте сумма nlogn становится незначительной, как и множитель k, то: O(N^2) ответ

P.S. Существует метод для не-аналитической оценки сложности алгоритма.

Берешь в цикле увеличиваешь размер входных данных и замеряешь скорость выполнения, строишь график где по Y откладываешь время, а по X - N и обычно точки ложатся в пределах какой либо функции: y=N;Y=N^2;Y=logN и т.д

5 миллионов записей для современных СУБД - это ерунда.
Было бы 5 миллиардов - можно было бы так заморачиваться, как вы хотите.

Дело в том, что вы не правильно организовали хранение фильтров.
Это действительно простой метод, но SQL в нормализованной форме не подходит для фильтров товаров по категориям товаров и интернет-магазине.
Нужна или ДЕНОРМАЛИЗОВАННАЯ форма с дублированием.
Или вообще БД другого типа. Я лично под такую задачу фильтрации предпочитаю Tarantool, но, полагаю, годится и Solr

Или, все же самый правильный вариант - это добавить памяти гигабайт до 16 и наслаждаться результатом? :)

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

Не надо учить паттерны. Надо понимать ООП. Чтобы понимать ООП, надо знать зачем оно нужно. Методология/парадигма - это подход к решению проблемы.
Значит ООП (а это парадигма) решает проблему.
Эту проблему необходимо ощутить на себе. Для этого нужна практика.

Мэт Задстра - отличный выбор для начала. Сам с него начинал.
Однако перед этим надо набить шишки. Только тогда, то, что описано в книге, будет воспринято как полезная информация.
Перед тем, как прочитать эту книгу я два года говнокодил.
Прочитал - зашло, подумал что всё понял.
Прочитал Фаулера. Ничего не понял.
Через полгода снова прочитал Фаулера. Подумал что теперь то уж точно всё понял.
Ан-нет.
Сейчас придерживаюсь взглядов на ООП Егора Бугаенко. Думаю что теперь то уж точно всё знаю.
Посмотрим что будет дальше.

Спасибо всем за ответы! Было интересно читать вашу дискуссию.

Я нашел интересные рассуждения на этот счет у Артема Горбунова. Процитирую:

«Дизайнерская работа априори предполагает циркуляцию идей, шаблонов и приёмов между проектами и клиентами. Если отнять круговорот идей, наша профессия перестанет существовать.

Где граница дозволенного, дизайнеру приходится решать самому. Если ко мне одновременно придут два банка, я не стану предлагать одному банку хитрую систему лояльности, о которой узнал в разговоре с другим. Если я сам придумал эту систему, с удовольствием предложу обоим. Но шаблон решения неизбежно отложится в голове и всплывёт в какой-нибудь другой задаче — так работает мозг. Идею нельзя скрыть, только задержать на время — если ей станет скучно в сундучке, она сама выпрыгнет в чьей-то чужой голове.

Это накладывает большую ответственность на дизайнера и объясняет клиентские страхи. Возможно, требование НДА означает неприятие клиентом этой реальности, и лучше не работать вместе. Поэтому я честно говорю всё это клиенту, когда заходит разговор о «секретности».

Мы учимся у клиентов за их счёт. Отблагодарить их мы можем только добросовестной работой и этичным поведением.

https://ru.wikipedia.org/wiki/OpenCV