This chapter matters because it offers not an abstract data platform, but a live evolutionary case: how a large company moves from a DWH model toward lakehouse and platform thinking without one magical leap.
In real engineering work, it helps you see a platform as a sequence of controlled steps: what to centralize, what to leave to domains, how to survive migration debt, and where shared capability ends and local team freedom begins.
In interviews and architecture discussions, it is especially useful when you need to talk not only about the target state, but also about the cost of getting there: ownership splits, change management, and accumulated architectural debt.
Practical value of this chapter
Design in practice
Shows enterprise data-platform evolution as a sequence of controlled architecture moves.
Decision quality
Provides guidance on when to centralize capabilities versus preserve domain autonomy.
Interview articulation
Strengthens answers with a real production operating-model example.
Risk and trade-offs
Focuses on transformation cost: migration debt, ownership split, and change management.
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.
References
Related chapters
- Evolution of T-Bank architecture - How the overall architectural outline of the company and platform engineering approach have changed.
- Data platforms: interview with Nikolay Golov - System compromises of building a data platform in 2025.
- Data Pipeline / ETL / ELT Architecture - Practice building an ingestion/transform/serving circuit.
- Apache Iceberg: table architecture in data lake - How open table formats support the lakehouse approach and data evolution.
- Technoshow “Dropped”: episode 1 - Practical analysis of the incident in the data platform and lessons learned for operation.