Langkau ke kandungan
Kembali ke Artikel
8 Februari 2026

Hujung Minggu Saya Dengan Buku System Design

Hujung minggu lepas, saya mengurung diri dan keluar daripada zon selesa dengan membaca buku "System Design Interview" oleh Alex Yu. Saya boleh katakan ia benar-benar membuka mata dan membuktikan betapa banyak lagi yang saya belum tahu tentang system design secara menyeluruh, trade-off, strategi, dan pendekatan untuk membuat pertimbangan teknikal ketika membina penyelesaian enterprise yang boleh dipercayai. Ia jauh lebih kompleks daripada apa yang biasa kita bina dalam projek peribadi, dan walaupun masih ada persamaan dengan perkara yang saya pelajari di universiti, terdapat banyak kemajuan baharu hanya dalam 2 hingga 3 tahun. Secara keseluruhan, saya melihat sistem dengan cara yang sangat berbeza selepas membacanya. Setiap kali saya membuka YouTube, saya mula memikirkan proses streaming hahaha, nerd betul. Sudah tentu, masih banyak lagi yang perlu diterokai kerana teknologi sentiasa berkembang, tetapi saya rasa saya sudah mula memahami apa yang diperlukan untuk menguasai beberapa domain dan mempunyai sebab yang kukuh bagi setiap keputusan teknikal ketika bekerja pada produk tertentu.

Artikel ini menjadi ringkasan pantas tentang perkara yang sempat saya tangkap sepanjang hujung minggu itu. Inilah bahagian yang saya maksudkan apabila saya kata saya mahu mendalami Software Engineering dan Infrastructure. Ini baru sekilas pandang; perkara yang lebih mendalam seperti reka bentuk umum Rate Limiter, Key Value Store, Unique Generated ID, dan Notification Services jauh lebih rumit apabila berurusan dengan enterprise yang mempunyai berjuta-juta Daily Active Users (DAU). Cara mengelakkan kehilangan data dan mengoptimumkan kos serta kecekapan masih memerlukan penerokaan lanjut, tetapi inilah arah pembelajaran yang saya mahu kejar tahun ini.

Selepas melaluinya, struktur ini penting untuk membimbing perbualan system design. Ia membantu mencapai persetujuan tentang reka bentuk yang dicadangkan atau membincangkan sebarang isu.

  1. Functional & Non Functional Requirement

    1. Jelaskan masalah - Tanya soalan tentang skala, keperluan data, dan kekangan.

    2. Tentukan skop - Fokus pada ciri penting dahulu sebelum mengoptimumkan.

  2. Back of an Envelope Estimation

    Sebelum membina, anda perlu mengira skala.

    • The Latency Table: Memahami perbezaan kelajuan antara L1 cache, SSD, dan network round-trip.

    • Storage & Bandwidth: Menganggarkan berapa banyak Petabyte storan yang diperlukan dalam 5 tahun supaya anda boleh memilih antara SQL DB biasa atau Data Lake.

  3. High Level Design

    1. Lakarkan seni bina - Kenal pasti komponen utama seperti API gateway, load balancer, cache, database, dan storage.

  4. Deep Dive Design

    1. Bincangkan trade-off - Terangkan kenapa anda memilih teknologi atau corak tertentu.

    2. Iterasi dan tambah baik - Akhiri dengan pengoptimuman dan pengendalian edge case.

pilihan reka bentuk peribadi

Sebagai permulaan, ini beberapa reka bentuk yang saya cadangkan untuk difahami. Ia bukan sahaja biasa, tetapi juga membantu menambah pengetahuan dalam beberapa kawasan penting.

  1. URL Shorteners

Cabaran di sini nampak mudah tetapi sebenarnya rumit: bagaimana menukar URL panjang kepada string pendek 7 aksara tanpa memberikan short code yang sama kepada dua URL berbeza? Satu cara biasa ialah menggunakan Hash Function, yang menawarkan dua penyelesaian baik untuk masalah collision:

  1. Gunakan hash function untuk menukar URL panjang kepada string 7 aksara, seperti CRC32, MD5, atau SHA-1. Ini kaedah lama, tetapi boleh ditambah baik dengan menambah string tertentu sebelum hashing. Kekurangannya ialah ia tidak boleh mengelakkan collision sepenuhnya, dan menyemak database untuk short URL sedia ada boleh menjadi mahal. Menggunakan bloom filters boleh membantu.

  2. Base conversion ialah satu lagi kaedah popular untuk URL shortener.

Jadual perbandingan ini daripada ByteBytego.com

| Hash + collision resolution | Base 62 conversion | | --- | --- | | Panjang short URL tetap. | Panjang short URL tidak tetap. Ia meningkat bersama ID. | | Tidak memerlukan unique ID generator. | Pilihan ini bergantung pada unique ID generator. | | Collision boleh berlaku dan perlu diselesaikan. | Collision tidak berlaku kerana ID adalah unik. | | Tidak mungkin untuk mengetahui short URL seterusnya kerana ia tidak bergantung pada ID. | Mudah untuk mengetahui short URL seterusnya jika ID meningkat sebanyak 1 bagi entri baharu. Ini boleh menjadi isu keselamatan. |

  1. Platform riders/drivers seperti Uber atau Grab

Langkah pertama ialah menentukan apa yang ingin dicapai, skalanya, dan apa yang platform ini boleh lakukan, dengan fokus pada aspek Functional dan Non-Functional.

  1. Pengguna boleh memasukkan lokasi mula dan destinasi.

  2. Selepas permintaan dibuat, rider perlu dipadankan dengan driver berdekatan.

  3. Driver boleh menerima atau menolak permintaan pickup/drop-off.

Kita juga boleh menyebut ciri tambahan seperti CICD, Fault Tolerance, driver ratings, dan Car Type untuk menunjukkan pemikiran produk. Setelah keperluan jelas, kita boleh mengenal pasti entity dan API yang diperlukan untuk memenuhi keperluan functional. (Nota: Tidak semestinya perlu menentukan data type untuk entity; elakkan momen yang membosankan semasa interview dan pastikan pilihan anda dijelaskan). Untuk keselamatan, nyatakan bahawa authentication dilakukan menggunakan Header JWT Token. Selepas entity dan API ditentukan, bergerak kepada High-Level Design. Dalam bahagian Deep Dive, individu senior boleh menunjukkan kepakaran mereka, tetapi sangat baik juga jika seseorang di tahap Mid-Level boleh menerangkan pemahaman mereka tentang setiap komponen dan berkongsi pengalaman peribadi. Pendekatan ini bertujuan meningkatkan prestasi, kebolehpercayaan, dan scalability.

lagi dan lagi

Sejujurnya, terlalu banyak perkara yang boleh dibincangkan, tetapi jika saya perlu menonjolkan satu perkara, corak-corak ini agak serupa dari segi struktur. Memang dijangka kita tidak tahu semuanya tentang setiap reka bentuk, tetapi kita patut mampu mencetuskan idea dan perbualan berdasarkan apa yang kita tahu.

real-time message & streaming

  • Messaging: Pilihan antara WebSockets untuk komunikasi dua hala dan low-latency, atau Long Polling sebagai fallback.

  • Video Streaming: Menggunakan DAG (Directed Acyclic Graph) untuk transcoding. Apabila video dimuat naik, ia dipecahkan kepada chunk dan diproses secara selari untuk menghasilkan resolusi berbeza seperti 1080p, 720p, dan 4k bagi CDN.

microservices

Walaupun kebanyakan buku ini tidak membincangkan microservices, kemungkinan kerana microservices bukan reka bentuk sistem yang tipikal. Ia hanyalah cara untuk memisahkan service, sama seperti monolith, tetapi dengan kelebihan dan kekurangan yang berbeza untuk pasukan.

Manfaat: Modularity, Scalability, Integration, Distributed Development, Fault Isolation Kritikan: Complexity, Distributed System Overhead, Data Management Challenges

Ini repositori yang berbaloi diterokai untuk memahami microservices dalam amalan: GitHub - Retail Store Sample Microservices AWS

Di bawah ialah senibinanya:

![architecture.png](https://github.com/aws-containers/retail-store-sample-app/blob/main/docs/images/architecture.png?raw=true align="center")

seni bina umum

Ini ialah ciri umum yang terdapat dalam kebanyakan sistem dan berbaloi disebut dalam setiap reka bentuk.

1. Scalability: Up vs. Out

  • Vertical (Scale Up): Membeli server yang lebih besar. Ia mudah tetapi ada had.

  • Horizontal (Scale Out): Menambah lebih banyak server. Ini ialah standard industri untuk aplikasi dengan daily active users yang tinggi. Kita menggunakan Load Balancers dan Database Sharding untuk menjayakannya.

2. Trade-off CAP Theorem

Dalam sistem teragih, anda hanya boleh memilih dua.

  • Banking? Anda memilih Consistency (CP). Lebih baik aplikasi "down" daripada menunjukkan baki yang salah.

  • Social Media? Anda memilih Availability (AP). Tidak mengapa jika "Like" mengambil 2 saat untuk muncul kepada rakan anda, selagi feed terus boleh diskrol.

3. Reliability & Fault Tolerance

Engineer senior merancang untuk kegagalan.

  • Idempotency: Penting untuk pembayaran. Jika pengguna menekan "Pay" dua kali kerana lag, Idempotency Key memastikan mereka hanya dicaj sekali.

  • Graceful Degradation: Jika service "Recommendations" down, skrin utama Netflix masih patut menunjukkan senarai "Continue Watching" dan bukan error 404.

pemikiran

Dalam dunia teknologi Malaysia, anda mungkin tidak sempat membincangkan semua butiran dalam interview 45 minit. Namun, matlamatnya ialah mencetuskan perbualan.

Ia bukan tentang mengetahui semuanya; ia tentang memiliki toolkit corak seperti Caching, Asynchronous Processing (Kafka), dan Rate Limiting serta tahu bila perlu menggunakannya. Hujung minggu ini hanyalah sekilas pandang, tetapi ia jelas menetapkan arah pembelajaran saya tahun ini.

Saya juga mencipta repo peribadi untuk menjana pelbagai kemungkinan reka bentuk bagi apa-apa jenis system design sebagai rujukan pantas dan penyegar ingatan. Saya menyediakan strukturnya dan membiarkan model AI OPUS 4.5 menjana fail Markdown yang komprehensif.

beberapa sumber