mayton2019

Заказчик сам выбирает обычно. Исходя из денег. VPS или bare-metal. Насколько амбиций хватит.
В последнее время все тяготеют к Kubernetes. Он как-то динамичнее утилизирует доступные железки.
Если VPS подняли. Поставили ОС. Поставили софт .... и побежали твои денежки к облаку.
А с кубером так. Захотел бигдату посчитать. Написал джоб. Запустил в кубере. Джоб отработал 1 час.
И ты заплатил ровно за 1 час. Дисковые хранилища там почти бесплатны. По цене грязи.
Ну з IOPS в пике можно заплатить. Но в целом пока джобы не работают ты ничего не платишь.

Вот. Еще лямбды (AWS) и clound-functions (другие облаки) тоже потребляют по 1 центу за вызов.
И при этом ее хостинг тебя не волнует. Она поднимется на любой виртуалке где есть ресурсы.

Поэтому не bare-metal -> VPS. А все еще запутанее хитрее. Железо. Виртуализация. Потом что там...
контейнеризация... Потом FAAS. Функции. Вот поэтому вопрос звучит не какие сервера поднмиаются
а какой бизнес-функционал лучше летает на каком уровне этой лестницы.

Поскольку вопрос тегирован алгоритмами - человек пытается ИХ изучать а не контракт array.sort.

В науке и технике... в качестве алгоритма сортировки любят использовать сортировку Хоара.
Она-же Quick Sort. Еще в переводной литературе ее называют Быстрая сортировка делением.

Еще я где-то читал (не помню где! блин) что ядро Linux иногда использует для своих нужд HeapSort.
Или сортировку Пирамидой. Или пирамидальную. Достаточно быстрая и не требующая дополнительной памяти
вообще. По месту сортирует.

Более полное демо по алгоритмам с визуализацией здесь

https://www.youtube.com/watch?v=kPRA0W1kECg

Какую под капотом реализует JavaScript sort - чорт его знает. Но возможно одна из самых быстрых.

Мне кажется что проблема не в телеграм библиотеках а как всегда в классических вопросах С++.
Контроль над памятью например. И если взять за формулу что ТГ-бот - это типичное реактивное
приложение то преимуществ С++ здесь вобщем-то нет. Нету задач которые бы загрузили CPU.

А если задачу развивать в части интеграции например с MQ/документными БД (Mongo) или с
веб-апи криптовалют то окажется что С++ в такой интеграции стоит еще в 2 раза дороже
и во времени разработки и в поддержке. А конечному пользователю вообще плевать на чем
бакенд бота написан.

И окажется в сухом остатке что наговнячить бота на Node или на Python будет дешевле. И поддерживать
код тоже дешевле. Вносить изменения - легче и быстрее. Для бизнеса - вообще скорость внесения
изменений в продукт - это метрика №1. Кто вышел с маркетинг акцией в срок - тот заработал денег.

Если-бы я был бизнесом и хотел бы свой ТГ-бот то я-бы не вкладывался в С++ (хотя я уважаю этот язык).
Я-бы нанял команду Ноде-Жс и все было бы норм.

Напоминает игру "Сапер".

Возможно в WinForms не эффективно реализован поиск компонентов по имени
Controls.Find("checkBox" + i, true)
Да и вообще 256 элементов - для рантайма тяжело. Наверное они слишком громоздкие
и интеллектуальные чтоб делать из них сетку объектов. Тоесть это не те WindowsGDI объекты.
Это дотнетовские объексты со своей обвязкой. С очередями сообщений и прочее.

Попробуй создать Graphics и на нем нарисовать сетку чек-боксиков. Как сапере.
И мышко-клик обрабатывай. Я думаю это решит проблему.

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

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

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

Путей много. Можно завести 2 таблички. Одна для новых машин. Другая - для подержанных. Со
своими наборами пропертей. Тогда и индексы строить удобно.
И с точки зрения типизации этот подход верный. Если язык разработки (Python/PHP) различает
типы машин - то для каждого типа нужна отдельная табличка. Это в духе ORM.
Недостаток - надо делать union all двух таблиц если мы хотим делать поиск по общим пропертям.

Можно завести 1 табличку с полем типа JSON и свалить туда все проперти которые могут быть
опциональны для новых машин и для Б/У. Это делает схему более компактной. И поиск по основным
полям работает универсально. Для кастомных полей надо искать описание в MySQL языков работающих
с JSON (JSonPath) для того чтоб выбирать и фильтровать и индексировать их.

Можно поступить как в BigData. Свалить все проперти что есть в одну большую таблицу. Будет в ней
допустим 500 колонок. И большая часть из них - пустая. Заполняется null. Такая модель тоже работоспособна.
Но для человека наблюдающего глазами таблицу будет неудобно с ней работать. Особенно когда нужное
тебе поле находится где-то на 400х колонках и надо скроллить грид мышкой вправо чтоб хотя-бы прочитать
глазами значения. И эволюция такой схемы проходит тяжелее. Т.к. alter table обычно блокирует таблицу
от транзакций DML и нужен регламент что добавлять новую колонку.

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

Нам здесь в хабре трудно оценить их эффективность. Это - примерно тоже самое
что оценивать программу обучения ВУЗа.

С моей субъективной точки зрения план - хороший. Если-бы я решил что он плохой
то мне надо было-бы срочно предложить свой собственный план. У меня такого нет.

А учитывая что ты плаваешь в понимании нужности Django и сокетов - то ты тем более
не в состоянии даже критиковать этот план. Поэтому бери его. Учи. И скажи спасибо
что хотя-бы такое есть.