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 architecture 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 platform capabilities end and local team freedom begins.
In interviews and architecture discussions, it is especially useful when you need to discuss not only the target state, but also the cost of getting there: responsibility boundaries, change management, and accumulated architectural debt.
Practical value of this chapter
Design in practice
Shows 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
A review of the platform's evolution, current system landscape, and key architectural paths.
Brief overview of the T-Bank data platform shows how a data platform evolves as a company grows: from classic DWH approaches (Inmon/Kimball) to Data Lake and lakehouse architecture. At the scale of 17k+ users and 144M+ requests per month, the architecture becomes a set of specialized layers where ingestion, storage, processing, and governance are designed as one operating platform.
Platform scale
Evolution period
18+ years
A gradual move from classic DWH to Data Lake and then to a lakehouse architecture.
Platform users
17 000+
Engineers, analysts, and product teams work through a shared data platform surface.
Requests per month
144 million+
This load keeps scalability and latency work on the critical path.
Key systems
19
An end-to-end lifecycle: ingestion, storage, processing, governance, observability, and security.
Architectural blocks of the platform
Data ingestion and delivery
The ingestion and replication layer connects OLTP systems, event streams, and downstream data products.
Data Replication: BODS + Chrono
Legacy batch delivery and modern streaming replication for reliable change propagation.
Event Sourcing: SDP
A Streaming Data Transfer Platform shaped by Data Mesh principles for domain events.
Reverse ETL: Spheradian
Returns enriched data back into operational systems with latency down to 100 ms.
Architectural takeaways
At data-platform scale, one universal DBMS is not enough: different latency and throughput profiles need specialized storage and compute paths.
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: enriched data has to return to business flows quickly.
Platform resilience depends not only on technology, but also on organizational responsibility: clear owners, incident processes, and shared delivery standards.
Practical checklist
- Separate ingestion, storage, processing, and governance as architectural layers with explicit SLAs/SLOs.
- For each data product, capture the contract, owner, and backward-compatibility rules for schema changes.
- Plan multi-engine execution early: batch, streaming, and exploratory analytics usually need different engines.
- Treat data incident management as a required process, not as a postmortem habit after the first major outage.
References
Related chapters
- Evolution of T-Bank Architecture - How the company's broader architecture and platform-engineering approach evolved.
- Data platforms in 2025: interview with Nikolay Golov - System-level trade-offs in building a modern data platform in 2025.
- Data Pipeline / ETL / ELT Architecture - How ingestion, transformation, and serving paths fit together in data pipelines.
- Apache Iceberg: table architecture for data lakes - How open table formats support lakehouse design and controlled data evolution.
- Technoshow “Dropped”: episode 1 - A practical incident review for data-platform operations and recovery discipline.