A data product with real-time aggregation, analytics and public API access
DexList combines a web interface, Telegram access and a backend layer for aggregating DEX data and exposing liquidity analytics.
What the product needed to solve
On-chain data arrives continuously and needs validation, caching and controlled access before it becomes useful in a product interface. The system also needed to serve different access patterns through web, API and Telegram.
- Separated data processing, caching and product delivery concerns.
- Used task queues for work that should not block user-facing requests.
- Added public API and Telegram access around the same underlying data model.
- Designed monitoring and load control into the infrastructure layer.
The implemented product layer
Real-time on-chain data processing
Liquidity analytics and web product interface
Public API and Telegram bot
Redis caching, queues and multi-protocol DEX integrations
How the system was organized
The recorded stack includes Node.js, TypeScript, PostgreSQL, Redis, Kubernetes and WebSockets. The system uses separate paths for ingestion, processing, caching and delivery so spikes in one area do not automatically block the others.
The result is a data infrastructure and product layer that can expose the same domain through web, API and Telegram workflows.
Evidence boundary
- The case does not publish trading, traffic or uptime claims.
- On-chain data quality depends on upstream networks and protocol integrations.
The workflow remains clear on a phone
The mobile surface preserves the primary product action, hierarchy and account context instead of reducing the page to a compressed desktop layout.
Need a similar product or internal workflow?
Send the context and the first useful outcome. We will suggest a realistic implementation path.