Величезне дякую!
Згенерував всі словоформи завдяки цьому проєкту. Далі завантажу в БД й напишу клас, щоб робив відмінювання окремих слів й словосполучень.

Дякую 🙏

Дуже дякую, буду дивитись 🙏

их тоже

Добрый день, Alex

Вы правы, сейчас в пике приходит +/- 650 запросов в секунду. Они распределяются двумя фронтами на 7 app-серверов. Выходит примерно по 100 запросов в секунду на каждый сервер. Плюс на этих app-серверах сейчас еще находится по 30 демонов, которые постоянно перелапачивают данные (перерасчет склада, отправка вебхуков, расчет статистики и т.д.). Скоро перепишем этих демонов в трушные микросервисы и вынесем на отдельные сервера. В итоге app-ы смогут выдерживать большую нагрузку.

Что касается остальных серверов, то там кластера баз данных, другие хранилища (GlusterFS, Redis, RabbitMQ и т.д.), всевозможные дополнительные сервисы и сателитные продукты, а также дублирование части инфраструктуры в другом ДЦ, чтобы можно было легко переключиться на него в случае проблем в основном.

Доброе утро, Виталий.

Valeriy Shvets хорошо расписал три основных преимущества: масштабируемость, безопасность и maintenance — при работе с отдельными базами под каждого клиента. Это создает конечно немного геморроя в виде адаптации разных штук, которые с одной базой работают на ура, а с множеством — нет. Но в дальнейшем это дает отличный результат.

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

Нам не надо со своей стороны беспокоиться про создание id сущностей под каждого клиента, стандартный автоинкремент создает идентификаторы и в итоге у клиентов красивые неразрывные Id. Это очень им и нам помогает в работе.

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

И так далее. Это одно из лучших архитектурных решений, которые были приняты на начальном этапе развития проекта.

Мы не откатываем.

90-95% миграций зачастую либо добавляют новые данные и поля, либо же их изменения настолько просты, что можно быстро потом что-то исправить в случае необходимости. Оставшиеся же кейсы наоборот, настолько могут быть сложны, что создание методов для отката данных приведет к тому, что надо будет написать столько же или в два раз больше кода, чем основной.

Поэтому мы приняли решение забить на это и для сложных фич создать процесс перестраховки, который работает для нас на все 100%. В итоге мы экономим время разработчиков и они могут заниматься чем-то более полезным.

Для перестраховки в сложных случаях мы используем такой флоу:
1) Во-первых, все основные функции покрыты тестами. Соответственно мы знаем, что все, что работало ранее вот так, будет и дальше работать вот так.
2) Дальше мы валиваем такой код на beta2, beta3 или beta4 и переводим туда тестовые аккаунты наших сотрудников. А это может быть порядка 50-70 аккаунтов, с которыми каждый день работает техническая поддержка, менеджеры отдела продаж, QA-инженеры и сами программисты. Держим на этих аккаунтах код порядка недели. Обычно все мажорные баги, если они вдруг прошли тесты, отлавливаются на этом этапе.
3) После этого начинаем на эту ветку переводить клиентов по чуть-чуть раз в два дня: 10, 20, 50, 100 аккаунтов. Так код тестируется еще порядка одной иди двух недель. Параллельно устраняются минорные проблемы.
4) Дальше все по стандартному флоу: выливаем в beta, постепенно переливаем на testing, production и stable.

Все верно. У нас и сейчас разработчики не могут отдать QA на проверку неработающую или работающую не так как надо фичу.

Отдельно хочу заметить, что на ранних стадиях создания продуктовой компании, есть большие ограничения в средствах: время, деньги, люди. Поэтому надо стараться все делать максимально быстро и с минимальными временными затратами на лишние процессы. Иначе можно не дойти до точки самоокупаемости.

Бизнесу необходимо, чтобы их проблемы решались максимально быстро и качественно. Зачастую ошибку без теста и дебага на реальных и конкретных данных не исправить. Бизнес это понимает и соглашается.

Привет, Макс. Спасибо :)

Если честно, то мы никогда не пытались работать с ветками в рамках какого-то общепринятого подхода.

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

Возможно в будущем распишу чуть более детально, как мы работаем с ветками, как переносим клиентов между ними, как делаем #stoptheline для перелива. С какими трудностями столкнулись из-за этого.

Евгений, среди планшетных POS-систем мы сейчас действительно делим первое и второе место с немецкой orderbird. У нас темп подключения новых клиентов лучше, поэтому в 2020 году выйдем уже на четкое первое место.

Если же сравнивать в комплексе со стационарными POS-системами, то мы уступаем ряду европейских и российских систем автоматизации. В этом общем сегменте мы точно в десятке.