Cryptocurrency index aggregator
PHP
Development of the system within the project budget and natural growth of loads.
Stage 1: Verification of mathematical models and launch of services (0–6 months)
Task: Implementation of price collection, index calculation, and graph generation.
Solution: Deployment based on a monolithic CMS (WordPress) with recording in a relational database. During this period, logging, metric collection, mailing, and two-factor authentication were integrated. The hypothesis was successfully confirmed.
Stage 2: Profiling and optimization (6–12 months)
Task: The database volume reaches 12 million records, increased during the execution of analytical queries (Query Latency).
Solution: Horizontal partitioning of the table by periods was conducted and a complete redesign of SQL query structures under the new index matrix was performed, resulting in a multiple increase in performance.
Stage 3: Infrastructure transition (Current status: > 24 million rows)
Task: The growth of data volume, complexity of analytics, and the need to restore gaps in telemetry in real-time require a review of the architecture.
Solution: Another planned migration of the core to the production stack (Go), replacement of the relational database with a specialized Time-Series storage, and a decomposition system into microservices using brokers.
Investments in infrastructure were distributed with reference to the budget. Modernization was carried out only when the potential of current technologies was fully exhausted.
Stage 1: Verification of mathematical models and launch of services (0–6 months)
Task: Implementation of price collection, index calculation, and graph generation.
Solution: Deployment based on a monolithic CMS (WordPress) with recording in a relational database. During this period, logging, metric collection, mailing, and two-factor authentication were integrated. The hypothesis was successfully confirmed.
Stage 2: Profiling and optimization (6–12 months)
Task: The database volume reaches 12 million records, increased during the execution of analytical queries (Query Latency).
Solution: Horizontal partitioning of the table by periods was conducted and a complete redesign of SQL query structures under the new index matrix was performed, resulting in a multiple increase in performance.
Stage 3: Infrastructure transition (Current status: > 24 million rows)
Task: The growth of data volume, complexity of analytics, and the need to restore gaps in telemetry in real-time require a review of the architecture.
Solution: Another planned migration of the core to the production stack (Go), replacement of the relational database with a specialized Time-Series storage, and a decomposition system into microservices using brokers.
Investments in infrastructure were distributed with reference to the budget. Modernization was carried out only when the potential of current technologies was fully exhausted.