System design langkah demi langkah · Pelajaran 7 dari 7 · 14 menit

Contoh Studi Kasus System Design: Merancang Situs Ini

Studi kasus system design yang dikerjakan langsung: framework tujuh langkah diterapkan pada situs ini, dari requirements dan angka sampai titik lemahnya.

Oleh Matthews WongDitinjau pada 13 Oktober 2026

Poin utama

Studi kasus system design menerapkan satu framework yang bisa diulang pada sistem nyata: requirements, estimasi, API, model data, desain tingkat tinggi, deep dive, dan trade-off. Di sini sistemnya adalah situs ini: halaman hasil prerender di balik Cloudflare dan nginx, satu URL yang menjawab dalam HTML atau Markdown, API kecil dengan rate limit, dan satu container yang batasnya menentukan apa yang rusak lebih dulu.

Setelah pelajaran ini, Anda bisa

Menjalankan tujuh langkah framework pada sistem nyata, dengan hasil konkret di akhir setiap langkah.
Membaca requirements dan batas sebuah desain dari konfigurasinya, bukan menebaknya.
Menyebut komponen paling berisiko dan bottleneck pertama, serta menjelaskan harga setiap trade-off.

Lihat cara kerjanya

Ikuti diagramnya langkah demi langkah

Tekan Putar, atau melangkah dengan panah. Setiap langkah juga ditulis di bawah diagram.

Tujuh langkah, diterapkan pada situs ini

Requirements menyebut pembacanya, API dan model data menyusul, build mengubah konten menjadi file, kunjungan membaca salah satunya, URL yang sama menyajikan Markdown untuk agen, dan satu container menjadi batasnya.

Kita merancang situs ini dengan framework tujuh langkah: pembaca di kiri, Cloudflare dan satu server di tengah, proses build di bawah. Setiap langkah menambah satu lapisan.

Tombol: ← → langkah · Home / End · K putar atau jeda

Kita merancang situs ini dengan framework tujuh langkah: pembaca di kiri, Cloudflare dan satu server di tengah, proses build di bawah. Setiap langkah menambah satu lapisan.
Requirements: artikel berbahasa Inggris dan Indonesia yang terbaca tanpa JavaScript, dan URL yang sama dalam Markdown untuk agen. Angkanya sudah ada di konfigurasi: satu CPU, 512 MB.
mem_limit: 512m cpus: "1.0"
API: setiap halaman adalah GET, dan tiga endpoint POST ada di bawah /api/v1/ dengan batas per IP. Model data: tanpa database sama sekali; tulisan adalah file di git.
chat: 20, followups: 30, contact: 5,
Penulisan terjadi saat build. Push menjalankan CI, yang me-render semua tulisan dalam dua bahasa ke dalam image, jadi menyajikan halaman berarti membaca file.
// Prerender every blog post at build time (x2 locales via the root layout's // generateStaticParams).Tebak langkah berikutnya Pengunjung membuka sebuah tulisan. Apa yang dilakukan container? (Membaca file hasil prerender · Query ke database · Me-render halaman dari nol)
Desain tingkat tinggi: Cloudflare mem-proxy request, nginx menangani TLS dan meneruskannya ke container di loopback, lalu halamannya diambil langsung dari file hasil prerender.
Tebak langkah berikutnya Agen AI meminta URL yang sama dalam Markdown. Ke mana request-nya? (Ke HTML hasil prerender · Ke route Markdown terpisah · Dialihkan ke /md/)
Deep dive pada bagian paling berisiko: satu URL, dua isi. middleware.ts menulis ulang request yang meminta text/markdown ke route Markdown, yang menjawab dengan Vary: Accept.
if (prefersMarkdown(request.headers.get("accept")))
Bottleneck: satu container di satu server, diganti setiap deploy tanpa menunggu health check-nya. Trade-off: baca murah, build lambat. Langkah berikutnya: instance kedua.

Apa saja tujuh langkah studi kasus system design?

Setiap studi kasus di modul ini menjalankan tujuh langkah yang sama, dan setiap langkah menyerahkan sesuatu yang konkret ke langkah berikutnya: requirements, lalu estimasi, lalu API, lalu model data, lalu diagram tingkat tinggi jalur request, lalu deep dive ke bagian paling berisiko, lalu bottleneck dan trade-off. Urutannya penting karena setiap pilihan sesudahnya dinilai terhadap requirements dan angka. Diagram yang digambar sebelum keduanya hanyalah daftar nama tool.

Baca selengkapnya (1)

Soal latihan biasanya berupa produk yang belum pernah Anda bangun, misalnya URL shortener. Pelajaran ini melakukan kebalikannya dan merancang sistem yang setiap keputusannya bisa Anda periksa: situs ini. Setiap langkah berakhir di file nyata, bukan tebakan, dan bila repositori tidak menyimpan suatu angka, misalnya trafik harian, pelajaran ini mengatakannya alih-alih mengarangnya. Menolak mengarang angka adalah kebiasaan pertama yang diajarkan framework ini.

Bagaimana requirements dan angka membentuk situs ini?

Requirements fungsionalnya singkat. Pengunjung membaca artikel dan pelajaran dalam bahasa Inggris dan Indonesia di URL yang selalu membawa locale. Crawler dan agen AI harus mendapat teksnya tanpa menjalankan JavaScript, dan agen yang mengirim Accept: text/markdown mendapat Markdown di URL yang sama. Chatbot dan form kontak butuh API kecil. Di luar cakupan: akun, komentar, dan apa pun yang ditulis pengunjung, itulah sebabnya tidak ada database.

Baca selengkapnya (1)

Sisi non-fungsional adalah tempat angka berada, dan di sini angkanya tertulis. docker-compose.yml membatasi container pada memori 512 MB dan satu CPU. next.config.ts mengecilkan cache halaman di memori milik Next dari default 50 MB menjadi 16 MB, karena hampir setiap halaman di-prerender dan dibaca dari disk. lib/api/versioning.ts mengizinkan 20 request chat, 30 follow-up, dan 5 kontak per menit per IP klien. Trafik tidak tercatat di repositori, jadi estimasi yang berguna adalah biaya per request: halaman hasil prerender cukup dibaca dari file, sedangkan request chat memanggil model bahasa, dan perbedaan itulah alasan batasnya dipasang di API.

Seperti apa API, data, dan jalur request-nya?

API-nya sebagian besar berupa GET untuk halaman. Endpoint JSON membawa versinya di path, di bawah /api/v1/; path lama tanpa versi tetap menjawab sebagai alias yang deprecated, dan perubahan yang merusak akan dirilis sebagai /api/v2/, bukan dengan mengubah v1. Model datanya berupa file: BLOG_META menyimpan judul, deskripsi, keyword, dan tanggal setiap tulisan, file messages menyimpan isinya dalam dua bahasa, dan lib/blog-sources.json adalah indeks turunan yang ditolak oleh pemeriksaan prebuild bila sudah basi. Menulis data berarti git push.

Baca selengkapnya (1)

Saat build, generateStaticParams mendaftar setiap tulisan dan Next me-render masing-masing dalam dua locale. Saat request, Cloudflare mem-proxy request pengunjung dan, karena secara default tidak meng-cache HTML, meneruskannya ke server. nginx menangani TLS lalu meneruskannya ke container, yang hanya dipublikasikan di alamat loopback server, jadi tidak ada yang bisa mencapainya kecuali lewat nginx. Request di bawah /api/ melewati middleware dan langsung menuju route handler-nya.

Di mana desain ini pertama kali rusak, dan apa yang akan Anda ubah?

Bagian paling berisiko adalah satu URL dengan dua isi. middleware.ts mengirim request Markdown ke route-nya sendiri, yang menjawab dengan Vary: Accept agar cache membedakan berdasarkan header Accept. Halaman HTML yang di-render tidak bisa membawa header itu, karena page handler Next mengganti Vary saat render, seperti dicatat komentar di middleware itu sendiri. Saat ini kondisinya aman hanya karena edge tidak menyimpan HTML. Aktifkan cache HTML di edge tanpa menambahkan Vary: Accept di nginx, dan agen bisa menerima HTML, atau browser menerima Markdown.

Baca selengkapnya (2)

Bottleneck pertama adalah container tunggal. Ia satu proses di satu server, jadi crash atau penggantian container berarti jeda bagi setiap request yang tidak bisa dijawab Cloudflare sendiri, dan deploy menjalankan docker compose up -d tanpa --wait, sehingga pipeline sudah hijau sebelum container sehat. Instance kedua di belakang nginx adalah langkah berikutnya yang jelas, dan langkah itu membuka asumsi tersembunyi: lib/rate-limit.ts menyimpan penghitungnya di sebuah Map di dalam proses, jadi dua instance masing-masing akan mengizinkan batas penuh. State itu harus dipindahkan keluar sebelum tier ini bisa di-scale.

Trade-off-nya disengaja, dan menyebut harga setiap pilihan adalah langkah terakhir framework ini. Prerender memberi pembacaan yang murah dan bisa diprediksi dengan harga build yang lama, itulah sebabnya CI memulihkan build cache Next. Tanpa database, satu kelas kegagalan hilang dan setiap penulisan menjadi commit yang direview, dengan harga tidak ada konten dari pengunjung. Satu server membuat sistem cukup kecil untuk dijalankan satu orang, dengan harga tanpa redundansi.

Cara situs ini melakukannya

Konfigurasi nyata di balik pelajaran ini

Kutipan dari repositori yang membangun dan men-deploy situs ini, apa adanya.

next.config.ts:16-21

  // In-memory LRU for rendered pages, on top of the on-disk prerender cache.
  // Default is 50 MB. Nearly every route here is prerendered at build time and
  // read straight off disk, and Cloudflare absorbs the repeat traffic, so a
  // large resident cache buys little on a 2 GB VPS that also runs the other
  // self-hosted services. 16 MB still holds the hot pages.
  cacheMaxMemorySize: 16 * 1024 * 1024,

Langkah estimasi, ditulis sebagai konfigurasi. Komentarnya menyebut requirement-nya (halaman di-prerender dan dibaca dari disk), kendalanya (server kecil yang dipakai bersama layanan lain), dan keputusannya beserta angkanya. Itulah aturan framework dalam bentuk kecil: lekatkan angka pada setiap pilihan dan jelaskan alasannya.

lib/api/versioning.ts:32-44

/** Current endpoints; trailing slash because the site sets trailingSlash. */
export const API_PATHS = {
  chat: "/api/v1/chat/",
  followups: "/api/v1/chat/followups/",
  contact: "/api/v1/contact/",
} as const;

/** Requests per minute per client IP, enforced by each route. */
export const API_RATE_LIMITS = {
  chat: 20,
  followups: 30,
  contact: 5,
} as const satisfies Record<keyof typeof API_PATHS, number>;

Seluruh permukaan API beserta batasnya dalam satu modul. Route-route menegakkan angka ini, dan next.config.ts, deskripsi OpenAPI, serta panduan developer membacanya, jadi langkah API dalam desain tidak bisa melenceng dari yang benar-benar berjalan. Klausa satisfies membuat endpoint baru tanpa batas menjadi error tipe.

app/[locale]/(pages)/blog/[slug]/layout.tsx:169-173

// Prerender every blog post at build time (x2 locales via the root layout's
// generateStaticParams). Without this, all 300+ posts were rendered on demand.
export function generateStaticParams() {
  return Object.keys(BLOG_META).map((slug) => ({ slug }));
}

Model data dan desain tingkat tinggi bertemu di sini. Daftar tulisan adalah key dari BLOG_META, sebuah file di repositori, dan mengembalikannya dari generateStaticParams memindahkan proses render dari waktu request ke waktu build. Komentarnya mencatat alternatif yang digantikannya.

lib/rate-limit.ts:1-11

/**
 * Simple in-memory rate limiter for API routes
 * In production, consider using Redis (Upstash) for distributed rate limiting
 */

interface RateLimitEntry {
  count: number;
  resetTime: number;
}

const rateLimitMap = new Map<string, RateLimitEntry>();

Asumsi tersembunyi dari langkah bottleneck. Sebuah Map di satu proses benar selama prosesnya memang hanya satu. Komentar di file itu sendiri menyebut perbaikan yang akan dipaksakan oleh instance kedua: pindahkan penghitungnya ke penyimpanan bersama.

Yang sering rusak

Kesalahan yang benar-benar membuang waktu

Cache HTML di edge tanpa Vary: Accept
Satu URL menjawab HTML atau Markdown, dan response HTML tidak membawa Vary: Accept. Cache bersama yang menyimpannya akan memberikan salinan itu ke semua klien, apa pun yang diminta. Jauhkan HTML dari cache edge, atau tambahkan Vary: Accept di nginx lebih dulu, seperti kata komentar di middleware.ts.
Scale out dengan state di dalam proses
Tambahkan container kedua dan rate limiter in-memory diam-diam menggandakan setiap batas, karena setiap proses menghitung sendiri. Pindahkan state bersama, seperti penghitung rate limit, ke penyimpanan bersama sebelum menambah instance.
Deploy yang melaporkan sukses terlalu cepat
docker compose up -d selesai begitu container mulai berjalan, bukan begitu container sehat, jadi image yang rusak tetap membuat pipeline hijau. Flag --wait menunggu sampai service berjalan dan sehat, sehingga health check menjadi bagian dari deploy.
Memilih fitur tanpa mengukur biayanya
next.config.ts mencatat bahwa meng-encode satu gambar cover ke AVIF butuh 4 sampai 9 detik di server ini, dibandingkan sekitar 0,6 detik untuk WebP, jadi AVIF tetap dimatikan sampai edge meng-cache gambar yang sudah dioptimasi. Requirement yang tampak gratis bisa menjadi baris termahal dalam desain.

Render di setiap request atau prerender saat build
	Render per request	Prerender saat build (situs ini)
Kerja per tampilan halaman	Menjalankan kode yang menyusun halaman	Membaca file yang sudah ada
Perubahan konten tayang	Pada request berikutnya	Setelah build dan deploy berikutnya
Waktu build	Singkat	Bertambah setiap ada tulisan baru
Kebutuhan saat request	Sumber data dan CPU	Disk dan sedikit memori
Cocok untuk	Halaman yang berbeda per pengguna	Artikel yang berubah lewat commit

Coba sendiri

Lakukan di komputer Anda sendiri

Anda butuh curl dan terminal. Amati dulu desain situs ini dari luar, lalu jalankan tujuh langkahnya pada sistem milik Anda sendiri.

1
Ambil header sebuah tulisan. Cari server: cloudflare, x-nextjs-prerender yang menandai halaman hasil build, dan cf-cache-status yang menunjukkan apakah edge menjawab dari cache-nya.
```
curl -sI https://www.matthewswong.com/en/blog/system-design-interview-framework-step-by-step/ \
  | grep -iE "^(server|cf-cache-status|x-nextjs-prerender|vary|content-type)"
```

Minta URL yang sama dalam Markdown. Content type berubah menjadi text/markdown dan muncul baris Vary: Accept; bandingkan dengan response HTML di atas.

curl -s -D - -o /dev/null -H "Accept: text/markdown" \
  https://www.matthewswong.com/en/blog/system-design-interview-framework-step-by-step/ \
  | grep -iE "^(content-type|vary)"

3
Panggil path API dengan method yang salah. Jawabannya error JSON dengan code yang stabil dan petunjuk: batas API tetap memegang kontraknya walau Anda salah memakainya.
```
curl -s https://www.matthewswong.com/api/v1/contact/
```

Sekarang tulis tujuh langkah untuk sistem yang Anda jalankan atau pakai, satu baris per langkah, dan cocokkan setiap angka dengan file, bukan ingatan.

1. Requirements: functional, non-functional, out of scope
2. Numbers: limits already in config, cost per request
3. API: paths, methods, versioning
4. Data: what is stored where, what is derived
5. Request path: every hop from user to data
6. Deep dive: the riskiest component
7. Bottlenecks and trade-offs: what fails first, what each choice costs

Kuis singkat

Tiga pertanyaan sebelum lanjut

Pilih jawaban untuk melihat kenapa benar atau salah. Tidak ada yang disimpan atau dinilai, jadi tebak saja dengan bebas.

1.Diminta merancang situs ini dalam interview, Anda langsung memilih Postgres dan Redis. Langkah mana yang Anda lewati?
2.Browser lalu agen AI meminta URL yang sama. Cache di depan menyimpan HTML untuk browser tanpa Vary: Accept. Apa yang didapat agen?
3.Anda menambah container kedua di belakang nginx. Kini form kontak menerima hingga 10 pesan per menit dari satu IP. Kenapa?

Pikirkan dulu

Jawab dalam hati, lalu cek

1.Kenapa situs ini tidak punya database, dan apa harganya?Lihat jawabannya
Jawaban:Requirements-nya tidak berisi penulisan oleh pengunjung: konten datang sebagai commit dan di-prerender saat build. Harganya: tidak ada konten dari pengunjung, dan setiap perubahan konten butuh build serta deploy.
2.Kenapa meng-cache HTML situs ini di edge berisiko dengan kondisi sekarang?Lihat jawabannya
Jawaban:URL yang sama bisa menjawab Markdown, dan response HTML tidak membawa Vary: Accept, jadi cache bersama bisa memberikan satu representasi ke klien yang salah. Response Markdown membawa header itu.
3.Apa yang harus diubah sebelum container kedua bisa berjalan dengan aman?Lihat jawabannya
Jawaban:Penghitung rate limiter ada di sebuah Map di dalam satu proses; dengan dua container, masing-masing akan mengizinkan batas penuh. Penghitung itu harus dipindah ke penyimpanan bersama lebih dulu.

Baca modulnya

Semua artikel di modul ini, berurutan

Pelajaran di atas adalah petanya. Setiap artikel membahas satu bagiannya secara mendalam, lengkap dengan contoh.

Sumber

Sumber primer yang diperiksa pada tanggal riset. Ikuti tautannya untuk versi terbaru.

Pelajaran sebelumnyaMicroservice untuk Pemula: Batas Service, Sync vs Async, Queue

Ikuti diagramnya langkah demi langkah

Tujuh langkah, diterapkan pada situs ini

Apa saja tujuh langkah studi kasus system design?

Bagaimana requirements dan angka membentuk situs ini?

Seperti apa API, data, dan jalur request-nya?

Di mana desain ini pertama kali rusak, dan apa yang akan Anda ubah?

Konfigurasi nyata di balik pelajaran ini

Kesalahan yang benar-benar membuang waktu

Cache HTML di edge tanpa Vary: Accept

Scale out dengan state di dalam proses

Deploy yang melaporkan sukses terlalu cepat

Memilih fitur tanpa mengukur biayanya

Lakukan di komputer Anda sendiri

Tiga pertanyaan sebelum lanjut

Jawab dalam hati, lalu cek

Semua artikel di modul ini, berurutan

Sumber