Source
T-Bank Data Platform
Analysis of the evolution of the platform, the current landscape of systems and architectural contours.
Brief overview of the T-Bank data platform shows how the data platform evolves as the company grows: from classic DWH approaches (Inmon/Kimball) to Data Lake and Lakehouse. At the scale of 17k+ users and 144M+ requests per month, the architecture turns into a set of specialized layers where ingestion, storage, processing and governance are designed as a single platform.
Platform scale
Evolution period
18+ years
Consistent transition from classic DWH to Data Lake and further to Lakehouse.
Platform users
17 000+
Engineers, analysts and product teams use a single data contour.
Requests per month
144 million+
High load requires constant work on scalability and latency.
Key systems
19
End-to-end lifecycle: from ingestion and processing to governance, observability and security.
Architectural blocks of the platform
Data collection and transportation
The ingest/replication circuit, which connects OLTP, event streams and downstream data products.
Data Replication: BODS + Chrono
Historical batch circuit and modern streaming replication for stable delivery of changes.
Event Sourcing: SDP
Streaming Data Transfer Platform built using Data Mesh principles for domain streams.
Reverse ETL: Spheradian
Return enriched data back to operating systems with up to 100ms latency.
Architectural Conclusions
At the scale of a data platform, there cannot be one universal DBMS: specialized storage/compute circuits are needed for different latency and throughput profiles.
Data Contracts and the observability loop become critical: without them, an increase in the number of teams turns the platform into an unmanageable set of integrations.
Reverse ETL closes the gap between analytics and operational products: data should be returned to business flow in almost real time.
The stability of the platform is ensured not only by technology, but also by organizational ownership: clear owners, incident processes and uniform standards for data delivery.
Practical checklist
- Separate ingestion, storage, processing and governance as separate architectural layers with explicit SLAs/SLOs.
- For each data product, record contracts, owner, and backward compatibility when schemas change.
- Plan multi-engine execution in advance: the optimal engine for batch, stream and ad-hoc analytics is usually different.
- Implement data incident management as a mandatory process, rather than a post-factum practice, after the first major failure.