Memahami HLD: Cetak Biru Arsitektur yang Bikin Tim Gak Saling Nabrak

Series: Memahami SDLC — Part 4 dari 10

Tiga artikel sebelumnya kita udah bahas BRD (masalah bisnis), PRD (fitur yang harus dibangun), dan SRS (spesifikasi teknis detail). Sekarang kita naik ke level arsitektur: HLD — High-Level Design.

Kalau SRS bicara soal gimana cara ngukur sebuah fitur, HLD bicara soal gimana sistem ini bakal bekerja secara keseluruhan. HLD adalah cetak biru (blueprint) arsitektur yang menjawab pertanyaan: “Sistem ini terdiri dari komponen apa aja, dan gimana mereka saling ngomong?”

Tanpa HLD, developer akan mulai ngoding dengan asumsi masing-masing. Frontend bikin API call yang gak sesuai sama backend. Backend bikin database schema yang gak bisa dipake fitur lain. Microservices saling lempar data dengan format yang beda. Pokoknya chaos.

Apa Bedanya HLD sama SRS?

Dimensi	SRS	HLD
Pembaca	Developer, QA	Arsitek, Tech Lead, Developer senior
Fokus	Spesifikasi per fitur	Arsitektur keseluruhan sistem
Output	Detail endpoint, response code, validasi	Diagram komponen, data flow, technology stack
Level	Mikro (per fitur)	Makro (seluruh sistem)
Contoh	“GET /api/products return 200 dengan array produk”	“API Gateway → Product Service → PostgreSQL. Cache Redis di layer service”

Kenapa HLD Penting?

Coba bayangin lo mau bangun rumah. SRS itu kayak spesifikasi teknis: “kamar tidur ukuran 4×5 meter, pintu 80cm, jendela 60x120cm.” Tapi tanpa HLD, lo gak tau di mana posisi kamar tidur, di mana dapur, di mana kamar mandi, dan gimana jalur pipa airnya.

HLD itu denah rumah. Tanpa denah, tukang bangunan bisa aja bikin kamar tidur di tempat yang seharusnya jadi dapur. Dan di software development, itu artinya code yang harus di-refactor total pas integration testing.

Komponen Utama HLD

1. Diagram Arsitektur (C4 Level 1-2)

Ini jantungnya HLD. Biasanya pake standar C4 Model:

• Level 1 (System Context): Kotak besar “Sistem Kita” dikelilingi aktor dan sistem eksternal (User, Payment Gateway, Email Service, etc.)
• Level 2 (Container): Pecah sistem jadi container-container — Web App, Mobile App, Backend API, Database, Queue, Cache. Masing-masing punya tanggung jawab jelas.

Tools yang sering dipake: Draw.io (gratis), Lucidchart (berbayar), Mermaid.js (buat yang suka code-based), atau Excalidraw untuk whiteboard-style.

2. Tech Stack Decision

HLD harus jelas ngasih tau: stack apa yang dipake dan kenapa.

• Frontend: React/Next.js atau Vue/Nuxt? SPA atau SSR?
• Backend: Go, Node.js, Python, atau Java? Kenapa milih itu?
• Database: PostgreSQL, MySQL, atau MongoDB? Butuh read replica?
• Cache: Redis atau Memcached?
• Queue: RabbitMQ, Kafka, atau Redis Stream?
• Storage: Object storage (S3/MinIO) atau lokal?
• Deployment: Docker di VPS, Kubernetes, atau serverless?

Setiap pilihan harus ada reasoning-nya. “Kita pake Go karena butuh throughput tinggi dan memory rendah untuk 10.000 request/detik.” Bukan “Go lagi trend,” ya.

3. Data Flow Diagram

Ini nunjukin gimana data bergerak dari satu komponen ke komponen lain. Contohnya:

User → Login Page → Auth Service → JWT Token → Browser Cookie
                              ↓
                        Database User Table

Data flow diagram penting buat ngasih tau: di mana data disimpan, di mana data diproses, dan di mana bottleneck potensialnya.

4. Database Schema (High-Level)

Bukan detail kolom per kolom — itu nanti di LLD (Low-Level Design). HLD cukup ngasih tau entitas utama dan relasinya:

• Users → has many → Orders
• Orders → belongs to → Products
• Products → belongs to → Categories

ERD (Entity Relationship Diagram) sederhana udah cukup di tahap ini.

5. API Design (High-Level)

HLD juga nentuin pola komunikasi antar service:

• Synchronous: REST API atau gRPC — buat request-response langsung
• Asynchronous: Message queue — buat event yang gak perlu instant response
• WebSocket: Buat real-time communication (chat, notifikasi, live update)

Nomer endpoint gak perlu didetailin di sini — cukup kategorinya aja: “Semua operasi CRUD produk lewat REST API di /api/v1/products”

Contoh HLD: E-Commerce Sederhana

Anggap kita mau bikin e-commerce. Ini gambaran HLD level container:

┌─────────────────────────────────────────────────┐
│                    User                          │
└────┬────────────────────────────┬───────────────┘
     │ HTTP/HTTPS                  │ HTTP/HTTPS
     ▼                             ▼
┌──────────┐               ┌──────────────┐
│ Web App  │               │ Mobile App   │
│ (Next.js)│               │ (Flutter)    │
└────┬─────┘               └──────┬───────┘
     │                            │
     └──────────┬─────────────────┘
                │ API Call
                ▼
        ┌──────────────┐
        │ API Gateway  │
        │ (Kong/Nginx) │
        └──┬───────┬───┘
           │       │
           ▼       ▼
   ┌─────────┐ ┌──────────┐
   │ Auth    │ │ Product  │
   │ Service │ │ Service  │
   └────┬────┘ └────┬─────┘
        │           │
        ▼           ▼
   ┌─────────┐ ┌──────────┐ ┌─────────┐
   │ User DB │ │ Product  │ │ Redis   │
   │ (PG)    │ │ DB (PG)  │ │ Cache   │
   └─────────┘ └──────────┘ └─────────┘

Dari diagram ini, lo langsung bisa liat:

• Ada 2 client: Web (Next.js) dan Mobile (Flutter)
• Semua request lewat API Gateway (security + routing)
• Auth Service terpisah dari Product Service (microservices)
• Redis dipake buat cache product yang sering diakses
• Setiap service punya database sendiri (database-per-service pattern)

Kapan HLD Dibuat?

HLD dibuat setelah SRS disetujui dan sebelum coding dimulai.

Flow-nya:

BRD → PRD → SRS → HLD → LLD → Coding → Testing → Deploy

HLD biasanya dikerjain oleh System Architect atau Tech Lead, lalu di-review sama seluruh tim engineering. Kalau ada keputusan arsitektur yang salah, lebih baik ketauan di tahap HLD daripada pas udah coding 2 bulan dan harus rewrite dari awal.

Yang Sering Salah Soal HLD

“HLD cuma buat proyek gede”

Salah. Bahkan proyek kecil pun butuh HLD — cukup di whiteboard atau Mermaid diagram. HLD = alat komunikasi, bukan formalitas.

“HLD = diagram aja”

Diagram emang penting, tapi HLD juga termasuk tech stack decision, data flow, dan alasan di balik setiap pilihan arsitektur.

“HLD cukup sekali di awal”

HLD itu living document. Begitu ada perubahan arsitektur, HLD harus diupdate. Gak perlu ribet, cukup catat perubahan dan kenapa berubah.

Ringkasan

• HLD = Cetak biru arsitektur sistem — diagram komponen, data flow, tech stack
• Dibuat setelah SRS, sebelum coding — dikerjain arsitek/tech lead
• Bukan cuma diagram — termasuk reasoning tiap keputusan teknis
• Bikin tim gak saling nabrak — semua orang punya gambaran besar yang sama

Next: Part 5 — LLD (Low-Level Design) — dari cetak biru ke detail implementasi. Kita bedah class diagram, sequence diagram, dan gimana nentuin algoritma sebelum coding.