For such a more realtime-focused, data-centered application like an exchange, it's not the frontend or backend that matter much. In fact for that, they can do away with any of the popular frameworks like React/Vue/Angular for the frontend and Go/Python for the backend. For example uniswap's frontend (although much simpler than binance) is built in React. The main interesting part here would be how they are able to handle updating data so quickly. In my opinion, they might be heavily reliant on realtime processing systems like Kafka+Kafka Streams, Apache Flink or Apache Spark Stream or similar. For more processing heavy but not so real-time processing, they might be relying on OLAP and/or warehousing tools like Cassandra/Redshift. They could have also optimized few high frequent queries using NoSQL stores like mongodb (for persistance) and in-memory cache like Redis (for further perfomance boost to get millisecond latencies).

Developing a solution that collects Telemetry Data from different devices, nearly 1000 devices minimum and maximum 12000. Each device is sending 2 packets in 1 second. This is time-series data, and this data definition and different reports are saved on PostgreSQL. Like Building information, maintenance records, etc. I want to know about the best solution. This data is required for Math and ML to run different algorithms. Also, data is raw without definitions and information stored in PostgreSQL. Initially, I went with TimescaleDB due to PostgreSQL support, but to increase in sites, I started facing many issues with timescale DB in terms of flexibility of storing data.

My major requirement is also the replication of the database for reporting and different purposes. You may also suggest other options other than Druid and Cassandra. But an open source solution is appreciated.

There'd be a couple of thousands of customers with a similar data structure and a medium number of transactions per day, but the data volume is pretty high (Each customer has around 1 or 2 GB so it would sum up to roughly 2TB). The usage pattern is both read and write-heavy (writes are mostly made through a Windows app, but read operations are made by the user), and I need the historical data for analysis and aggregation. The data model is not join-heavy as is not join-free. If the solution is fully ACID, the better, but must be Highly Available and Horizontally Scalable.

Also, the budget is not so high, and I'd rather be using a handful (at most 5) of cheap to medium-sized servers (2 CPU cores and 4GB RAM).