System Design #1 — Arsitektur untuk Side Project yang (Mungkin) Viral

Hidup gue berubah pas gue ngelakuin kesalahan yang sama dua kali.

Pertama, gue bikin REST API pake microservices dari awal. 6 service. 6 database. 3 bahasa pemrograman. Butuh 4 bulan — dan pas launch, cuma 12 orang yang pake. Service-nya lebih sering down daripada serving request. Kenapa? Karena gue debugging masalah networking, bukan masalah user.

Kedua, gue bikin side project lain. Kali ini pake monolith. Satu binary, satu database. Launch 2 minggu — dan anehnya, ini yang survive sampe sekarang.

Side project yang gak pernah launch punya arsitektur terbaik di dunia — dan 0 user.

Instagram cuma punya 3 engineer waktu diakuisisi Facebook dengan 30 juta user. Twitter mulai sebagai monolith. Shopify juga. Polanya gak berubah.

Gue nulis ini karena 4 bulan pertama gue sia-sia mikirin microservices. Lo gak perlu ngulangin kesalahan yang sama.

Mulai dari Monolith — Kenapa Bukan Microservices

Monolith itu bukan dosa. Ini titik awal yang bener. Alasan semua orang pake monolith bukan karena males belajar — karena biaya distribusi (network latency, data consistency, debugging antar-service) jauh lebih mahal daripada keuntungan skalabilitas yang gak lo butuhin.

Yang penting bukan monolith vs microservices. Yang penting adalah: apakah kode lo separation of concern-nya rapi atau spaghetti?

Lihat: domain dipisahin berdasarkan business logic, bukan deployment unit. Ini penting — karena nanti kalo lo butuh mindahin satu domain ke service terpisah, yang lo butuh hanyalah ganti import, bukan refactor ulang.

Modular Monolith: Batasi dengan Interface, Bukan Service

Pas gue punya 200 user aktif, satu binary mulai terasa berat. Bukan skalanya — tapi gue nambahin feature image processing yang pake CPU gila-gilaan. API response jadi 3 detik.

Gue tadinya mikir: "Ini waktunya pisah service." Ternyata jawabannya lebih sederhana: pisahin interface, bukan pisahin deployment. Modular monolith.

Caranya: setiap domain cuma bisa akses domain lain lewat interface yang terdefinisi. Payment module gak bisa langsung akses database User — cuma lewat UserService interface.

Kalau nanti lo beneran perlu pisahin Payment jadi service sendiri, lo tinggal bikin implementasi remote dari interface yang sama. Kode bisnis gak berubah.

Pilih Stack yang Lo Kuasai, Bukan yang Lagi Hype

Ini pelajaran yang gue bayar mahal: jangan pake bahasa baru untuk side project pertama lo. Lo liat Hacker News — Zig, Gleam, Bun — langsung pengen pake. Hasilnya: 2 minggu belajar syntax, 2 minggu debugging tooling, side project gak jadi.

Gue pake Go bukan karena paling keren, tapi karena udah gue pake 3 tahun. Gue tau cara deploy, cara debug memory leak, cara setup CI/CD. Stack yang lo kuasai > stack yang lagi hype.

Untuk 2026: Go atau TypeScript buat backend. Postgres buat database. VPS $4/bulan dari Hetzner. Done.

Desain Database: Keputusan yang Paling Berdampak Jangka Panjang

Dari semua yang gue pernah refactor — framework, API, frontend — refactor database di production adalah yang paling sakit. Gak ada cari dan replace buat database.

Aturan gue sekarang: normalisasi sampe 3NF dulu. Denormalisasi cuma kalo ada benchmark yang jelas. UUID v7, bukan auto-increment. Timestamptz, bukan timestamp. Soft delete dengan deleted_at.

Schema yang baik bisa lo jelaskan dalam 3 kalimat. Kalo butuh 3 paragraf, terlalu kompleks.

Observability dari Hari Pertama, Bukan Nanti-nanti

Side project lo punya 0 user. Lo pikir: "Buat apa log?" Lo launch. Ada error. Lo gak tau error apa. Lo nyari-nyari manual. 3 jam hilang. Ini kejadian gue — dan gue sumpah gak akan ngulangi.

Dari day 1: structured logging (JSON format), request ID yang nembus semua log, health check endpoint (/healthz). Butuh 10 menit setup — menghemat berjam-jam debugging.

Automation: Karena Lo Solo, Lo Harus Efisien

Kalo lo sendiri, waktu adalah musuh. Setiap menit buat manual deploy, manual testing, manual backup adalah menit yang lo gak pake buat nulis fitur — atau lebih penting, istirahat.

Commit pertama: langsung setup CI/CD. Otomatis test + deploy tiap push ke main. Backup database tiap 6 jam. One-command deploy. Health check monitoring.

Kapan Split ke Microservices? (Jawaban Singkat: Hampir Gak Pernah)

Split pertama yang impactful bukan split service — tapi split process. Pisahin background worker dari web server. Itu cukup buat 99% side project.

Evolution path: monolith (0-100 user) → +worker (100-1000) → modular (ribuan). Indikator lo beneran butuh microservices: deploy cycle conflict. Kalo lo cuma 1 orang developer, ini gak akan terjadi.

Kalau side project lo punya 100 user dan lo udah mikirin microservices — lo mikirin masalah yang gak lo punya.

Cheat Sheet: Checklist Sebelum Nulis Baris Kode Pertama

• Define data model dulu — entity, relationship
• Pilih stack yang lo udah proven — bukan yang lagi hype
• Setup CI/CD dari commit pertama
• Satu endpoint health check — /healthz
• Structured logging — jangan pake fmt.Println
• Launch minimum viable product

Penutup — 4 Bulan Gak Kepake, Ini yang Gue Pelajari

Gue ngabisin 4 bulan pertama bikin microservices yang gak kepake. Apa yang gue pelajari: arsitektur yang baik bukan yang paling scalable. Arsitektur yang baik adalah yang bikin lo launch cepat, gampang diubah, dan — paling penting — gak bikin lo pengen quit.

Mulai dengan monolith. Pake Postgres. Observability dari hari pertama. Automation everything.

Karena side project yang gak pernah launch punya arsitektur terbaik di dunia — dan 0 user.

📎 Referensi

1.

Paket database/sql

2.

PostgreSQL Docs

3.

Package log/slog

4.

GitHub Actions