Intermediate

Designing Good Data Architecture

9 Principles of good data architecture and modern architectural patterns

⏱️ 40 min read 📅 Updated Jan 2025 👤 Based on "Fundamentals of Data Engineering" by Joe Reis & Matt Housley

            🎯 Learning Objectives
            Memahami 9 Principles of Good Data Architecture
Bisa memilih antara Monolith vs Microservices
Mengenal Lambda vs Kappa Architecture
Memahami konsep Data Mesh
Bisa mengaplikasikan architectural patterns di dunia nyata

        

Mode Baca Pemula

Topik arsitektur bisa terasa abstrak. Fokus dulu ke:

Definisi data architecture
Prinsip arsitektur yang paling relevan
Pattern dasar sebelum masuk data mesh

Kamus istilah: DE-GLOSSARY.md

Prasyarat Ringan

Paham lifecycle data engineering secara umum
Pernah melihat minimal satu data pipeline end-to-end
Tahu perbedaan sistem operasional vs sistem analitik

Istilah Penting (3 Lapis)

Istilah: Data Architecture

Definisi awam: Cetak biru cara sistem data dibangun.

Definisi teknis: Desain struktur komponen, alur data, serta prinsip reliability, scalability, dan governance.

Contoh praktis: Menentukan bagaimana data dari OLTP masuk lakehouse lalu disajikan ke BI/API.

Istilah: Data Mesh

Definisi awam: Data dikelola per domain bisnis, bukan satu tim pusat saja.

Definisi teknis: Arsitektur domain-oriented dengan data-as-a-product dan federated governance.

Contoh praktis: Tim Finance dan Growth punya data product dengan owner dan SLA masing-masing.

Apa itu Data Architecture?

Data Architecture adalah blueprint dari sistem data kamu. Ini menjawab pertanyaan: Bagaimana data bergerak dari sumber ke konsumen? Bagaimana komponen-komponen saling berhubungan? Bagaimana sistem akan scale dan evolve seiring waktu?

⚠️ Architecture vs Implementation

Architecture adalah "what" dan "why", sedangkan implementation adalah "how". Architecture harus stabil dan timeless, sementara technologies berubah terus.

The 9 Principles of Good Data Architecture

Berikut adalah 9 principles yang ditetapkan oleh Joe Reis & Matt Housley dalam buknya:

Choose Common Components Wisely

Pilih komponen yang bisa digunakan bersama (shared services) tapi jangan terlalu banyak. Contoh: Gunakan satu data warehouse untuk semua tim, tapi jangan paksakan semua tim pakai tools yang sama untuk analysis.

Plan for Failure

Design sistem yang resilient. Komponen akan fail, network akan down, data akan corrupt. Pertanyaannya bukan "if" tapi "when". Implement redundancy, backup, dan disaster recovery.

Architect for Scalability

Plan untuk growth. Apa yang works untuk 1GB data mungkin tidak works untuk 1PB. Pertimbangkan horizontal vs vertical scaling, partitioning, dan distributed systems.

Architecture Is Leadership

Data Architect bukan hanya technical role tapi juga leadership. Kamu perlu:

Communicate vision ke stakeholders
Balance technical debt dengan delivery
Mentor engineers dan promote best practices

Always Be Architecting

Architecture adalah continuous process, bukan one-time activity. Requirements berubah, technologies evolve, dan architecture harus adapt.

Build Loosely Coupled Systems

Komponen harus independent. Jika satu service down, services lain tetap berjalan. Gunakan APIs, message queues, dan event-driven architecture untuk decoupling.

Make Reversible Decisions

Avoid irreversible decisions. Pilih technologies dan patterns yang bisa diubah jika kebutuhan berubah. Abstract away vendor-specific features untuk avoid vendor lock-in.

Prioritize Security

Security bukan afterthought. Design dengan security mindset dari awal:

Principle of least privilege
Encryption at rest dan in transit
PII handling dan data masking
Audit logging

Embrace FinOps

Cost adalah first-class citizen dalam architecture. Cloud costs bisa spiral out of control. Monitor costs, set budgets, dan optimize resource allocation.

Architectural Patterns

Monolith vs Microservices

Aspect	Monolith	Microservices
Complexity	Lower (single codebase)	Higher (distributed systems)
Deployment	All-or-nothing	Independent deployments
Scalability	Scale everything together	Scale individual services
Team Structure	Small teams	Multiple autonomous teams
Best For	Startups, small teams, simple domains	Large orgs, complex domains, scale needs

💡 The Distributed Monolith Trap

Banyak yang "migrate to microservices" tapi end up dengan distributed monolith - services yang tightly coupled sehingga harus deploy bareng. Ini worst of both worlds: complexity of microservices tanpa benefitsnya.

Lambda Architecture

Lambda Architecture adalah pattern untuk handling both batch and real-time data:

Lambda Architecture Layers

🔄 Batch Layer (Slow)
Process all historical data. High latency (hours), high accuracy.

⚡ Speed Layer (Fast)
Process real-time data. Low latency (seconds), approximate results.

📊 Serving Layer
Merge batch + speed views untuk complete picture.

🛒 Contoh: E-commerce Analytics

Batch Layer: Daily comprehensive sales report (akurat, tapi 1 hari delay)
Speed Layer: Real-time current hour sales (kurang akurat karena exclude refunds)
Serving Layer: Dashboard yang nunjukkan "yesterday complete + today approximate"

Kappa Architecture

Kappa Architecture adalah simplified version: streaming only. Semua data dianggap stream, termasuk "batch" yang sebenarnya adalah bounded streams.

            ✅ When to Use Kappa over Lambda
            Jika real-time adalah default requirement
Jika tooling untuk stream processing sudah mature (Kafka, Flink)
Jika ingin avoid complexity of maintaining two code paths

        

Data Mesh

Data Mesh adalah architectural paradigm yang berpikir data sebagai product dan mendistribusikan ownership ke domain teams.

The 4 Principles of Data Mesh

1️⃣ Domain Ownership

Domain teams own their data end-to-end

2️⃣ Data as a Product

Treat data with same rigor as software products

3️⃣ Self-Serve Platform

Platform team provides infrastructure, domains build

4️⃣ Federated Governance

Global standards with local autonomy

🏦 Contoh: Bank dengan Data Mesh

Sebuah bank memiliki beberapa domain:

Retail Banking Domain: Own customer accounts, transactions data
Credit Card Domain: Own credit card transactions, payments
Loan Domain: Own loan applications, repayments

Setiap domain punya data product owner yang bertanggung jawab untuk: data quality, documentation, dan serving data ke consumers lain.

Case Study: Architecture Evolution

📈 Evolution of Gojek's Data Architecture

Phase 1: Monolith (2015-2017)

Single PostgreSQL database
Daily cron jobs untuk reports
Simple, tapi tidak scalable

Phase 2: Lambda Architecture (2017-2019)

Batch: Hadoop untuk historical analytics
Speed: Kafka + Storm untuk real-time
Complexity meningkat, maintenance berat

Phase 3: Stream-First / Kappa (2019-2021)

Kafka sebagai source of truth
Flink untuk stream processing
Simplified architecture, unified code base

Phase 4: Data Mesh (2021-present)

Domain-oriented ownership
Self-serve data platform
Federated governance

Decision Framework: Architecture Choices

Decision Point	Pilih Opsi A Jika...	Pilih Opsi B Jika...
Monolith vs Modular	Tim kecil, scope produk masih awal	Domain kompleks, ownership tim terpisah
Central platform vs Domain-owned	Governance ingin ketat dan standar seragam	Butuh otonomi domain dan time-to-market cepat
Build vs Buy	Kebutuhan sangat spesifik dan strategic moat	Use case umum tersedia mature managed solution

Failure Modes & Anti-Patterns

            Anti-Patterns Arsitektur
            Overengineering day-1: arsitektur terlalu kompleks sebelum ada kebutuhan nyata.
No ownership model: komponen kritikal tidak punya team owner jelas.
Ignoring failure domains: satu gangguan menjatuhkan seluruh pipeline.
Architecture by vendor slide: keputusan tidak berbasis constraint internal.

        

Production Readiness Checklist

            Checklist Architecture Review
            Dependency map antar komponen terdokumentasi.
Failure scenario utama sudah diuji (tabletop/chaos ringan).
SLO per komponen dan data product jelas.
Observability baseline aktif (logs, metrics, lineage).
Biaya operasional dipantau per domain.
Security controls masuk dari fase desain.

        

✏️ Exercise: Design an Architecture

Kamu adalah Data Architect di Tokopedia. Design architecture untuk sistem berikut:

Requirements:

10M+ daily transactions
Real-time fraud detection (sub-second latency)
Daily comprehensive business reports
Self-service analytics untuk 50+ data analysts
ML models untuk recommendation (batch training, real-time inference)

Pertanyaan:

Lambda atau Kappa architecture? Kenapa?
Monolith atau Microservices? Trade-offs apa?
Apa 3 principles yang paling penting untuk use case ini?
Apakah Data Mesh cocok untuk organisasi ini? Kenapa?

🎯 Quick Quiz

1. Principle mana yang menekankan importance of cost management?

A. Plan for Failure

B. Embrace FinOps

C. Always Be Architecting

D. Build Loosely Coupled Systems

2. Dalam Lambda Architecture, layer mana yang menangani real-time data?

A. Batch Layer

B. Speed Layer

C. Serving Layer

D. Storage Layer

3. Apa keuntungan utama Kappa vs Lambda?

A. Lebih cepat dalam processing

B. Hanya satu code path untuk maintain

C. Lebih murah dalam storage

D. Lebih mudah untuk debugging

Key Takeaways

            🎯 Summary
            9 Principles: Common components, failure planning, scalability, leadership, continuous architecting, loose coupling, reversible decisions, security, FinOps
Lambda: Batch + Speed layers, complex tapi flexible
Kappa: Streaming only, simplified, good untuk mature organizations
Data Mesh: Domain ownership, data as product, self-serve platform, federated governance
Architecture adalah trade-offs, tidak ada one-size-fits-all

        

📚 References & Resources

Primary Sources

Fundamentals of Data Engineering - Joe Reis & Matt Housley (O'Reilly, 2022)
Chapter 5: Designing Data Architecture
Designing Data-Intensive Applications - Martin Kleppmann (O'Reilly, 2017)
Chapter 1: Reliable, Scalable, Maintainable Applications
Data Mesh - Zhamak Dehghani (O'Reilly, 2022)
Part I: The Data Mesh Paradigm