Tujuan Pembelajaran

Mengerti database sharding strategies
Bisa mendesain distributed database architecture
Mengerti distributed system challenges dan solusinya

Analogi

Diagram


      Database Scaling:
Vertical -> Bigger server (CPU/RAM/disk)
Horizontal:
  ├── Read Replication -> Master writes, replicas read
  ├── Sharding -> Split data across servers
  └── Federation -> Split by function (users_db, orders_db)

Vertical scaling punya limit fisik — horizontal scaling adalah jangka panjang, tapi jauh lebih kompleks

Penjelasan Konsep

Ketika single database server tidak bisa handle load, kita perlu scale horizontally. Ada beberapa strategi dengan trade-off berbeda.

Read Replication

Master server menerima semua writes, replica servers menerima reads. Cocok untuk read-heavy workload (80%+ reads). Replication lag bisa jadi issue — data di replica mungkin sedikit outdated.

Database Sharding

Memisahkan data ke multiple database servers berdasarkan shard key.

Strategies: Range-based (user_id 1-1M di shard A, 1M-2M di shard B — hot spot risk), Hash-based (hash(user_id) % N — distribusi merata, tapi resharding sulit),

Directory-based (lookup table menentukan shard — flexible, tapi single point of lookup).

Federation

Memisahkan database berdasarkan domain — users database, orders database, products database.

Cocok untuk microservices architecture.

Distributed Challenges

Data consistency across shards (two-phase commit, Saga pattern), Cross-shard queries (joins jadi sulit, perlu application-level join), Resharding (ketika shard penuh — online resharding tanpa downtime),

Global secondary indexes (query berdasarkan non-shard-key field).

Anti-Patterns

Shared database antara services (coupling), Sharding tanpa business justification (premature optimization), Cross-shard transactions (sebisa dihindari, gunakan Saga pattern).

Inti yang Perlu Dipahami

Bagian ini berfokus pada mengerti database sharding strategies., bisa mendesain distributed database architecture., dan mengerti distributed system challenges dan solusinya. Jangan terburu-buru menghafal istilahnya. Lebih penting untuk memahami peran setiap konsep dan kapan konsep itu muncul dalam pekerjaan web development.

Saat membaca Database Sharding, Replication, dan Distributed Systems, gunakan tujuan belajar sebagai penanda arah. Kalau kamu sudah bisa menjelaskan tujuan itu dengan kata-katamu sendiri, berarti fondasinya mulai terbentuk.

Cara Membayangkannya

Vertical scaling punya limit fisik — horizontal scaling adalah jangka panjang, tapi jauh lebih kompleks. Analogi ini dipakai supaya konsep teknis tidak terasa melayang. Hubungkan setiap istilah dengan perannya: siapa yang meminta, siapa yang memproses, data apa yang berpindah, dan hasil apa yang diharapkan.

Kalau analoginya sudah terasa masuk akal, barulah lihat istilah teknisnya. Cara ini membuat materi lebih mudah dipahami daripada langsung menghafal definisi.

Saat Melihat Contoh Kode

Contoh kode pada chapter ini memakai bahasa typescript. Bacalah contoh kode sebagai ilustrasi alur, bukan sebagai bagian yang harus langsung dihafal. Consistent hashing: hash shard key, modulo jumlah shard untuk menentukan target. Saga pattern: eksekusi step sequential, kalau gagal jalankan compensating transaction untuk undo step yang sudah berhasil.

Perhatikan nama fungsi, urutan langkah, dan data yang berpindah. Biasanya tiga hal itu sudah cukup untuk memahami hubungan antara teori dan praktik.

Konteks dalam Perjalanan Belajar

Setiap konsep di platform ini dipilih karena dipakai di industri. Fokus pada pemahaman, bukan hafalan.

Kamu sudah di bagian lanjutan. Mulai pikirkan bagaimana konsep ini dipakai di dunia kerja — bukan hanya untuk belajar, tapi untuk membangun produk nyata.

Gunakan pertanyaan reflektif dan prompt AI di akhir chapter sebagai latihan aktif. Membaca saja tidak cukup — kamu perlu menjelaskan ulang dengan kata-katamu sendiri.

Contoh Kode

typescript

// Consistent hashing untuk sharding
class ShardRouter {
  private shards: string[];
  
  constructor(shardUrls: string[]) {
    this.shards = shardUrls;
  }
  
  getShard(key: string): string {
    const hash = this.hashCode(key);
    const index = Math.abs(hash) % this.shards.length;
    return this.shards[index];
  }
  
  private hashCode(str: string): number {
    let hash = 0;
    for (let i = 0; i < str.length; i++) {
      hash = ((hash << 5) - hash) + str.charCodeAt(i);
      hash |= 0;
  }
    return hash;
  }
}

// Penggunaan
const router = new ShardRouter([
  'postgresql://shard1/db',
  'postgresql://shard2/db',
  'postgresql://shard3/db',
]);

function getUserShard(userId: string) {
  return router.getShard(userId);
}

// Saga pattern untuk distributed transaction
async function createOrderSaga(orderData: OrderData) {
  const steps = [
    { service: 'inventory', action: 'reserve', compensate: 'release' },
    { service: 'payment', action: 'charge', compensate: 'refund' },
    { service: 'shipping', action: 'create', compensate: 'cancel' },
  ];
  
  const completed: string[] = [];
  
  try {
    for (const step of steps) {
      await executeStep(step.service, step.action, orderData);
      completed.push(step.service);
    }
  } catch (error) {
    // Compensating transaction: undo semua step yang sudah berhasil
    for (const service of completed.reverse()) {
      const step = steps.find(s => s.service === service)!;
      await executeStep(service, step.compensate, orderData);
    }
    throw new Error(`Order failed, compensated: ${error}`);
  }
}

Penjelasan Kode

Consistent hashing: hash shard key, modulo jumlah shard untuk menentukan target. Saga pattern: eksekusi step sequential, kalau gagal jalankan compensating transaction untuk undo step yang sudah berhasil.

Prompt AI

Desain sharding strategy untuk platform e-commerce dengan 10 juta users dan 100 juta orders. Pilih shard key yang tepat dan rencanakan resharding strategy.

Pertanyaan Reflektif

Distributed systems secara fundamental lebih kompleks dari monolith. Jangan distributed kalau belum perlu. Premature database scaling adalah anti-pattern — scale kalau metrics menunjukkan bottleneck, bukan karena mungkin butuh.