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

• Availability

• Partition Tolerance

2. BASE

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

• B

• S

• E

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

1. OCP

1. LSP

1. ISP

1. DIP

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