Агрегатор криптовалютних індексів
PHP
Розвиток системи в рамках проектного бюджету та природного зростання навантажень.
Етап 1: Перевірка математичних моделей і запуск сервісів (0–6 міс.)
Задача: Реалізація збору прайсов, розрахунку індексів і виведення графіків.
Рішення: Розвертання на базі монолітної CMS (WordPress) із записом в реляційну БД. У цей же період інтегровано логування, збір метрик, розсилки та двофакторну авторизацію. Гіпотеза успішно підтверджена.
Етап 2: Профілювання та оптимізація (6–12 міс.)
Задача: Об’єм бази даних досягає 12 мільйонів записів, збільшилося під час виконання аналітичних виборів (Query Latency).
Рішення: Проведено горизонтальне партиціонування таблиці за періодами та повну переробку структур SQL-запитів під нову матрицю індексів, що дало кратний приріст продуктивності.
Етап 3: Інфраструктурний перехід (Поточний статус: > 24 млн строк)
Задача: Зростання обсягу даних, ускладнення аналітики та необхідність відновлення пропусків (розривів) у телеметрії в реальному часі вимагають перегляду архітектури.
Рішення: черговий плановий переклад ядра на виробничий стек (Go), заміна реляційної БД на спеціалізоване хранилище Time-Series і система декомпозиції на мікросервіси з використанням брокерів.
Інвестиції в інфраструктуру розподілялися з прив'язкою до бюджету. Модернізація проводилася тільки тоді, коли потенціал поточних технологій був повністю вичерпаний.
Етап 1: Перевірка математичних моделей і запуск сервісів (0–6 міс.)
Задача: Реалізація збору прайсов, розрахунку індексів і виведення графіків.
Рішення: Розвертання на базі монолітної CMS (WordPress) із записом в реляційну БД. У цей же період інтегровано логування, збір метрик, розсилки та двофакторну авторизацію. Гіпотеза успішно підтверджена.
Етап 2: Профілювання та оптимізація (6–12 міс.)
Задача: Об’єм бази даних досягає 12 мільйонів записів, збільшилося під час виконання аналітичних виборів (Query Latency).
Рішення: Проведено горизонтальне партиціонування таблиці за періодами та повну переробку структур SQL-запитів під нову матрицю індексів, що дало кратний приріст продуктивності.
Етап 3: Інфраструктурний перехід (Поточний статус: > 24 млн строк)
Задача: Зростання обсягу даних, ускладнення аналітики та необхідність відновлення пропусків (розривів) у телеметрії в реальному часі вимагають перегляду архітектури.
Рішення: черговий плановий переклад ядра на виробничий стек (Go), заміна реляційної БД на спеціалізоване хранилище Time-Series і система декомпозиції на мікросервіси з використанням брокерів.
Інвестиції в інфраструктуру розподілялися з прив'язкою до бюджету. Модернізація проводилася тільки тоді, коли потенціал поточних технологій був повністю вичерпаний.