Mengenal Akronim Penting dalam System Design: CAP, BASE, SOLID, KISS

Pendahuluan

Dalam dunia system design, ada beberapa akronim fundamental yang wajib dipahami oleh setiap System Analyst dan Software Engineer. Artikel ini membahas empat yang paling penting.

1. CAP Theorem

CAP Theorem menyatakan bahwa penyimpanan data terdistribusi hanya bisa memberikan dua dari tiga jaminan berikut:

• Consistency — Setiap read menerima write terbaru atau error
• Availability — Setiap request menerima response
• Partition Tolerance — Sistem tetap berjalan ketika terjadi kesalahan jaringan

2. BASE

Model ACID (Atomicity-Consistency-Isolation-Durability) pada relational database terlalu strict untuk NoSQL. Prinsip BASE menawarkan fleksibilitas lebih:

• Basically Available — Sistem selalu tersedia
• Soft state — State sistem bisa berubah seiring waktu
• Eventually consistent — Data akan konsisten pada akhirnya

BASE memilih availability dibanding consistency — cocok untuk sistem yang butuh high availability seperti social media atau e-commerce.

3. SOLID Principle

Lima prinsip desain object-oriented:

1. SRP (Single Responsibility Principle) — Satu class, satu tanggung jawab
2. OCP (Open/Closed Principle) — Open for extension, closed for modification
3. LSP (Liskov Substitution Principle) — Subclass harus bisa menggantikan parent class
4. ISP (Interface Segregation Principle) — Interface yang spesifik lebih baik dari yang umum
5. DIP (Dependency Inversion Principle) — Bergantung pada abstraksi, bukan implementasi

4. KISS

"Keep It Simple, Stupid!"

Prinsip desain yang pertama kali dirumuskan oleh U.S. Navy pada 1960. Sebagian besar sistem akan bekerja paling baik jika dibuat sederhana.

Penerapan KISS dalam System Design:

• Jangan over-engineer solusi
• Pilih arsitektur yang sesuai skala, bukan yang paling canggih
• Dokumentasi yang jelas lebih baik dari desain yang kompleks

Contoh: CAP Theorem dalam Memilih Database

Visualisasi trade-off CAP saat memilih database untuk berbagai kebutuhan:

flowchart TD
    CAP["CAP Theorem"] --> CP["CP: Consistency + Partition Tolerance"]
    CAP --> AP["AP: Availability + Partition Tolerance"]
    CAP --> CA["CA: Consistency + Availability"]

    CP --> DB1["MongoDB"]
    CP --> DB2["Redis"]
    CP --> DB3["HBase"]

    AP --> DB4["Cassandra"]
    AP --> DB5["DynamoDB"]
    AP --> DB6["CouchDB"]

    CA --> DB7["PostgreSQL"]
    CA --> DB8["MySQL"]
    CA --> DB9["SQL Server"]

    style CP fill:#4CAF50,color:#fff
    style AP fill:#2196F3,color:#fff
    style CA fill:#FF9800,color:#fff

Contoh: SOLID Principle dalam Class Design

Contoh penerapan Single Responsibility Principle (SRP) pada sebuah sistem order:

classDiagram
    class OrderService {
        +createOrder(items)
        +cancelOrder(orderId)
        +getOrderStatus(orderId)
    }

    class PaymentService {
        +processPayment(orderId, method)
        +refundPayment(paymentId)
        +getPaymentStatus(paymentId)
    }

    class NotificationService {
        +sendEmail(to, subject, body)
        +sendSMS(to, message)
        +sendPushNotification(userId, message)
    }

    class InventoryService {
        +checkStock(productId)
        +reserveStock(productId, qty)
        +releaseStock(productId, qty)
    }

    OrderService --> PaymentService : uses
    OrderService --> NotificationService : uses
    OrderService --> InventoryService : uses

Setiap class hanya punya satu tanggung jawab — OrderService tidak mengurus payment atau notifikasi secara langsung.

Kapan Menggunakan Apa?

Ditulis oleh Dadang Kriswanto — System Analyst & Blogger di dadang.kriswanto.my.id

Baca Juga

• System Design untuk Proyek B2B
• Implementasi SOLID di WordPress Plugin