SSOT #

Dalam sistem software modern—terutama yang berskala besar, terdistribusi, dan dikembangkan oleh banyak tim—konsistensi data dan logika adalah tantangan utama. Banyak bug, inkonsistensi, dan kompleksitas muncul bukan karena algoritma yang salah, tetapi karena informasi yang sama direpresentasikan di banyak tempat.

Di sinilah SSOT (Single Source of Truth) berperan sebagai prinsip fundamental dalam software engineering.

SSOT menekankan bahwa setiap data, konfigurasi, atau aturan bisnis harus memiliki satu sumber utama yang dianggap paling benar, dan semua bagian sistem lain harus mengacu ke sumber tersebut.

Apa Itu SSOT? #

Single Source of Truth (SSOT) adalah prinsip desain yang menyatakan bahwa:

Untuk setiap potongan data atau logika penting dalam sistem, harus ada satu dan hanya satu sumber yang bersifat otoritatif.

Artinya:

• Tidak ada duplikasi makna
• Tidak ada versi “mirip tapi beda”
• Tidak ada asumsi implisit di banyak tempat

Jika data atau aturan berubah, perubahan dilakukan di satu tempat, dan seluruh sistem otomatis mengikuti.

Masalah yang Terjadi Tanpa SSOT #

Tanpa SSOT, sistem biasanya mengalami:

Data Tidak Konsisten #

Contoh:

• Status user ACTIVE didefinisikan di backend A
• Backend B menganggap ENABLED
• Frontend punya mapping sendiri

Hasilnya:

• Bug aneh
• Edge case sulit direproduksi
• Debugging mahal

Duplikasi Logic Bisnis #

• Validasi umur ditulis ulang di banyak service
• Perhitungan harga ada di API dan worker
• Konfigurasi retry berbeda-beda

Biaya Maintenance Tinggi #

• Setiap perubahan harus update banyak file
• Risiko lupa update satu tempat
• Perubahan kecil jadi high-risk

SSOT Tidak Selalu Tentang Database #

Kesalahan umum adalah menganggap SSOT = satu database.

Padahal SSOT bisa berupa:

• Modul kode
• Package library
• Schema
• Service tertentu
• File konfigurasi
• Contract API

Yang penting otoritasnya jelas, bukan lokasinya.

Area Umum Penerapan SSOT #

Data Model & Domain Rules #

• Enum
• Status
• Konstanta bisnis

Konfigurasi #

• Feature flag
• Timeout
• Retry policy

Validasi #

• Input validation
• Business validation

Contract & Schema #

• API schema
• Event schema
• Message format

Contoh SSOT Menggunakan Golang #

Contoh Buruk (Tanpa SSOT) #

// service_a/status.go
const StatusActive = "ACTIVE"
const StatusInactive = "INACTIVE"

// service_b/user.go
func IsUserEnabled(status string) bool {
    return status == "ENABLED" // berbeda makna
}

Masalah:

• Makna status tidak konsisten
• Sulit dikontrol

Contoh Baik: SSOT dengan Package Domain #

// domain/user/status.go
package user

type Status string

const (
    StatusActive   Status = "ACTIVE"
    StatusInactive Status = "INACTIVE"
)

func (s Status) IsActive() bool {
    return s == StatusActive
}

Penggunaan:

// service_a/handler.go
if user.Status.IsActive() {
    // logic
}

// service_b/worker.go
if user.Status.IsActive() {
    // logic yang sama
}

Status dan maknanya hanya didefinisikan sekali.

SSOT untuk Business Logic #

Centralized Pricing Rule #

// domain/pricing/pricing.go
package pricing

type PriceCalculator struct {
    TaxRate float64
}

func (p PriceCalculator) FinalPrice(base float64) float64 {
    return base + (base * p.TaxRate)
}

Pemakaian:

calculator := pricing.PriceCalculator{TaxRate: 0.11}
price := calculator.FinalPrice(100_000)

Tidak ada logic pajak tersebar di banyak tempat.

SSOT untuk Konfigurasi #

Central Config Loader #

// config/config.go
package config

import "os"

type Config struct {
    AppName string
    Timeout int
}

func Load() Config {
    return Config{
        AppName: os.Getenv("APP_NAME"),
        Timeout: 30,
    }
}

Digunakan di seluruh aplikasi:

cfg := config.Load()

Config tidak di-hardcode ulang di banyak tempat.

SSOT dalam Arsitektur Microservices #

SSOT tidak berarti semua service boleh akses langsung ke satu database.

Prinsip yang benar:

• Setiap service adalah SSOT untuk domain-nya
• Service lain mengakses melalui API atau event

Contoh:

• User Service = SSOT untuk user data
• Order Service tidak menyimpan ulang user status

SSOT vs DRY #

SSOT dan DRY saling melengkapi, bukan saling menggantikan.

Kapan SSOT Bisa Menjadi Overkill? #

SSOT tidak selalu gratis.

Hati-hati jika:

• Sistem sangat kecil
• Over-abstraction membuat kode sulit dibaca
• Shared package terlalu gemuk

Gunakan SSOT pada hal yang benar-benar penting dan sering berubah.

Best Practice SSOT #

1. Tentukan owner untuk setiap data & rule
2. Buat boundary yang jelas
3. Gunakan naming eksplisit
4. Jangan expose internal detail
5. Dokumentasikan SSOT dengan baik

Kesimpulan #

Prinsip Single Source of Truth (SSOT) adalah fondasi penting untuk:

• Konsistensi
• Skalabilitas
• Maintainability
• Kepercayaan pada sistem

Dengan Golang—yang kuat dalam modularitas dan eksplisit—SSOT dapat diterapkan secara elegan melalui:

• Package domain
• Central config
• Shared contract

Jika sebuah kebenaran ada di dua tempat, cepat atau lambat salah satunya akan bohong.

SSOT membantu memastikan hanya ada satu kebenaran yang dipercaya.