Bagian A — Pilihan Ganda HOTS (20 Soal)
Narasi Kasus: Sebuah startup di Bukittinggi membangun aplikasi pariwisata berbasis sistem terdistribusi. Founder mengklaim sistem mereka "100% fault-tolerant dan selalu konsisten". Setelah 6 bulan operasional, terjadi downtime 4 jam saat salah satu data center mengalami banjir.
Berdasarkan Teorema CAP dan teori sistem terdistribusi, klaim founder tersebut secara fundamental salah karena...
- A. Sistem terdistribusi tidak mungkin mencapai 100% fault tolerance karena selalu ada single point of failure tersembunyi.
- B. Teorema CAP membuktikan bahwa Consistency, Availability, dan Partition Tolerance tidak bisa dicapai bersamaan — klaim "selalu konsisten + selalu tersedia" adalah mustahil saat terjadi partition.
- C. Sistem terdistribusi hanya cocok untuk perusahaan besar dengan budget miliaran.
- D. Fault tolerance hanya bisa dicapai dengan replikasi data ke minimal 100 node.
- E. Banjir adalah force majeure yang tidak bisa diantisipasi oleh sistem apapun.
Narasi Kasus: E-commerce "TokoSumbar" awalnya monolitik, lalu di-migrate ke microservices. Setelah migrasi, latency meningkat 300ms karena setiap request user memicu 15-20 panggilan antar-service. Developer mengeluh debugging menjadi sangat sulit.
Masalah mendasar dari migrasi yang tidak tepat ini adalah...
- A. Microservices selalu lebih lambat dari monolith — migrasi seharusnya tidak dilakukan.
- B. Granularitas service terlalu kecil (over-decomposition) menyebabkan chattiness antar-service; seharusnya menggunakan bounded context yang tepat.
- C. Microservices membutuhkan database terpisah untuk setiap service, yang selalu meningkatkan latency.
- D. Migrasi ke microservices hanya cocok untuk perusahaan dengan tim DevOps minimal 50 orang.
- E. Monolith lebih mudah di-scale secara horizontal daripada microservices.
Narasi Kasus: Sistem monitoring kesehatan pasien ICU menggunakan message broker (RabbitMQ) untuk mengirim data vital sign dari sensor ke dashboard perawat. Ketika broker crash selama 10 detik, data dari 50 sensor hilang karena menggunakan mode non-persistent.
Solusi arsitektural paling tepat untuk sistem kritis seperti ini adalah...
- A. Mengganti RabbitMQ dengan REST API synchronous agar data tidak hilang.
- B. Menggunakan persistent message queue dengan acknowledgement, dead letter queue, dan publisher confirms untuk guarantee delivery.
- C. Menambah jumlah broker menjadi 10 untuk load balancing.
- D. Menyimpan data di sensor dan mengirim ulang setiap 1 jam.
- E. Menggunakan UDP karena lebih cepat dari TCP.
Narasi Kasus: Pemerintah Provinsi Sumatera Barat membangun API Gateway untuk integrasi 50 layanan publik (SIM card, pajak, KTP, dll). Beberapa layanan legacy masih menggunakan SOAP, sementara layanan baru menggunakan REST dan GraphQL.
Peran paling kritis dari API Gateway dalam skenario heterogen ini adalah...
- A. Mengganti semua layanan legacy menjadi REST secara otomatis.
- B. Berfungsi sebagai facade yang menerjemahkan protokol, melakukan routing, rate limiting, authentication terpusat, dan observability lintas layanan yang heterogen.
- C. Menyimpan cache dari semua response layanan untuk mempercepat akses.
- D. Menghapus kebutuhan akan dokumentasi API karena gateway otomatis generate docs.
- E. Menjamin semua layanan memiliki latency di bawah 50ms.
Narasi Kasus: Sistem blockchain private untuk sertifikasi tanah di Sumatera Barat menggunakan 7 node validator (BPN, Pemda, Pengadilan, Notaris, dll). Mereka menggunakan konsensus Raft. Ketika 3 node mengalami kegagalan bersamaan akibat gempa, sistem berhenti memproses transaksi.
Analisis paling tepat terhadap kegagalan ini adalah...
- A. Raft membutuhkan mayoritas (N/2 + 1) node aktif; dengan 7 node, minimal 4 harus aktif. 3 failure = 4 aktif, seharusnya masih berjalan — kemungkinan ada bug implementasi.
- B. Raft tidak cocok untuk blockchain; seharusnya menggunakan Proof of Work.
- C. Sistem seharusnya menggunakan 100 node agar tahan terhadap 3 failure.
- D. Gempa adalah force majeure yang tidak bisa di-handle oleh algoritma konsensus manapun.
- E. Seharusnya menggunakan Paxos karena lebih superior dari Raft.
Narasi Kasus: Aplikasi ride-hailing di Padang menampilkan harga yang berbeda untuk user yang sama dalam waktu 5 detik karena replikasi eventual consistency antara 3 data center. User komplain di media sosial, viral, dan merusak reputasi brand.
Keputusan desain yang paling tepat untuk menghindari masalah ini tanpa mengorbankan performa secara signifikan adalah...
- A. Menggunakan strong consistency global untuk semua data — harga selalu sama di mana saja.
- B. Menerapkan session consistency per user + sticky session ke region terdekat, dengan invalidasi cache proaktif saat harga berubah.
- C. Menonaktifkan replikasi dan menggunakan single data center di Jakarta.
- D. Menampilkan disclaimer "harga dapat berubah" di UI tanpa mengubah arsitektur.
- E. Menggunakan blockchain untuk menyimpan harga agar immutable.
Narasi Kasus: Sistem e-government Sumatera Barat menggunakan strategi active-passive disaster recovery dengan RPO 1 jam dan RTO 4 jam. Ketika data center utama terbakar, backup di kota lain berhasil di-activate, namun data transaksi 45 menit sebelum kebakaran hilang permanen.
Evaluasi paling kritis terhadap strategi DR ini untuk sistem pemerintahan adalah...
- A. RPO 1 jam sudah cukup baik untuk sistem pemerintahan.
- B. Untuk data transaksi pemerintahan (pajak, perizinan), RPO 1 jam tidak dapat diterima — seharusnya menggunakan synchronous replication atau CDC (Change Data Capture) dengan RPO mendekati nol.
- C. Kebakaran adalah force majeure, kehilangan data 45 menit dapat ditoleransi.
- D. Seharusnya menggunakan 3 data center bukan 2.
- E. RTO 4 jam terlalu cepat, seharusnya 24 jam agar lebih hemat biaya.
Narasi Kasus: Sistem perbankan digital menggunakan OAuth 2.0 dengan JWT untuk autentikasi. Seorang attacker berhasil mencuri refresh token dari device user dan menggunakannya untuk mendapatkan access token baru, mengakses rekening korban selama 30 hari sebelum terdeteksi.
Kerentanan mendasar dalam implementasi OAuth 2.0 ini adalah...
- A. OAuth 2.0 secara inheren tidak aman untuk perbankan.
- B. Tidak ada mekanisme token revocation, refresh token rotation, dan anomaly detection — refresh token yang dicuri tetap valid hingga expired.
- C. JWT tidak bisa di-encrypt sehingga payload bisa dibaca attacker.
- D. Seharusnya menggunakan SAML bukan OAuth 2.0.
- E. Access token seharusnya memiliki lifetime 30 hari, bukan refresh token.
Narasi Kasus: Rumah sakit menyimpan data pasien terenkripsi AES-256 di cloud. Ketika terjadi ransomware attack, attacker mengenkripsi ulang data dengan key mereka. Backup juga terenkripsi dengan key yang sama dan disimpan di lokasi yang sama. Rumah sakit kehilangan akses ke data selama 2 minggu.
Pelanggaran prinsip keamanan paling fundamental dalam kasus ini adalah...
- A. AES-256 sudah tidak aman dan seharusnya menggunakan AES-512.
- B. Pelanggaran prinsip "3-2-1 backup rule" dan pemisahan key management dari data — backup seharusnya offline/immutable dengan key terpisah.
- C. Cloud storage secara inheren tidak aman untuk data medis.
- D. Seharusnya menggunakan enkripsi quantum-proof.
- E. Ransomware hanya bisa dicegah dengan antivirus, bukan arsitektur.
Narasi Kasus: Startup fintech membangun sistem dengan 200 microservices. Service discovery menggunakan DNS tradisional dengan TTL 5 menit. Ketika sebuah service di-scale dari 3 ke 30 instance, 5 menit pertama request masih di-route ke instance lama yang sudah di-terminate, menyebabkan 15% error rate.
Solusi paling tepat untuk masalah service discovery dinamis ini adalah...
- A. Menurunkan TTL DNS menjadi 1 detik untuk semua record.
- B. Menggunakan service mesh (seperti Istio/Linkerd) dengan sidecar proxy yang melakukan service discovery real-time via control plane, bypassing DNS TTL limitation.
- C. Menonaktifkan auto-scaling agar IP tidak berubah.
- D. Menggunakan static IP untuk setiap instance service.
- E. Menambah jumlah DNS server menjadi 10.
Narasi Teori: Distributed Hash Table (DHT) seperti Chord dan Kademlia digunakan untuk peer-to-peer lookup. Sebuah sistem file sharing P2P menggunakan DHT dengan 10.000 node. Ketika 40% node meninggalkan jaringan secara bersamaan (flash crowd), lookup time meningkat drastis.
Penyebab fundamental degradasi performa DHT dalam skenario ini adalah...
- A. DHT membutuhkan server pusat untuk indexing yang crash.
- B. Routing table di setiap node menjadi stale — finger table perlu waktu untuk stabilisasi, dan banyak key menjadi unreachable hingga stabilisasi selesai.
- C. DHT hanya bekerja dengan maksimal 1.000 node.
- D. Flash crowd selalu menyebabkan DHT crash permanen.
- E. Chord tidak mendukung node departure, hanya Kademlia yang mendukung.
Narasi Kasus: Universitas menggunakan NFS (Network File System) untuk shared storage dosen. Ketika 100 dosen mengakses file yang sama secara bersamaan untuk upload nilai, NFS server menjadi bottleneck dan beberapa write operation hilang karena tidak ada file locking yang proper.
Perbandingan solusi manakah yang paling tepat untuk kasus ini?
- A. NFS sudah cukup, cukup tambah RAM server.
- B. Migrasi ke distributed file system modern seperti Ceph atau GlusterFS yang mendukung distributed locking, consistent hashing, dan replikasi otomatis — lebih skalabel dan reliable daripada NFS tradisional.
- C. Menggunakan FTP server terpisah untuk setiap dosen.
- D. Menyimpan file di USB flash drive dan di-share manual.
- E. Menggunakan Google Drive tanpa integrasi sistem akademik.
Narasi Kasus: Sistem arsip digital nasional menggunakan distributed file system dengan erasure coding (10+4) untuk durability. Ketika 4 node storage gagal bersamaan, data tetap bisa di-reconstruct. Namun, reconstruction time memakan waktu 72 jam, selama itu data berada dalam keadaan "degraded".
Trade-off paling kritis dari erasure coding dibanding replikasi penuh (3x replica) adalah...
- A. Erasure coding lebih boros storage daripada replikasi 3x.
- B. Erasure coding lebih efisien storage (1.4x vs 3x) namun reconstruction lebih lambat dan CPU-intensive; replikasi lebih cepat recovery tapi boros storage.
- C. Erasure coding tidak bisa tolerate node failure sama sekali.
- D. Replikasi 3x selalu lebih superior dalam semua aspek.
- E. Erasure coding hanya cocok untuk data yang tidak penting.
Narasi Kasus: Startup edutech di Bukittinggi memilih antara: (a) IaaS (AWS EC2), (b) PaaS (Heroku), (c) Serverless (AWS Lambda), (d) On-premise. Trafik mereka sangat fluktuatif: 100 user di malam hari, 50.000 user saat jam sekolah. Tim hanya terdiri dari 3 developer.
Pilihan deployment model paling rasional berdasarkan constraint tim dan pola trafik adalah...
- A. On-premise — paling hemat biaya jangka panjang.
- B. IaaS dengan auto-scaling — kontrol penuh atas infrastruktur.
- C. Serverless (FaaS) — auto-scaling granular, pay-per-execution, minimal operational overhead untuk tim kecil dengan trafik sangat fluktuatif.
- D. PaaS — paling mudah digunakan tanpa pertimbangan biaya.
- E. Hybrid cloud dengan 50% on-premise dan 50% cloud.
Narasi Kasus: Perusahaan migrasi dari VM-based ke container-based (Kubernetes) deployment. Setelah migrasi, mereka mengalami masalah: container sering di-restart, stateful application (database) kehilangan data, dan networking antar container kompleks.
Kesalahan fundamental dalam migrasi ini adalah...
- A. Kubernetes tidak cocok untuk production environment.
- B. Memperlakukan semua workload sama — stateful workload (database) seharusnya menggunakan StatefulSet dengan persistent volume, bukan Deployment biasa; dan tidak semua aplikasi cocok di-containerize tanpa modifikasi arsitektur.
- C. Seharusnya menggunakan Docker Swarm bukan Kubernetes.
- D. Container secara inheren tidak aman untuk database.
- E. Migrasi ke container selalu menyebabkan data loss.
Narasi Kasus: Sistem e-commerce menggunakan distributed transaction dengan Two-Phase Commit (2PC) untuk memastikan konsistensi antara service order, inventory, dan payment. Ketika payment service slow response, coordinator timeout dan seluruh transaction di-abort. User complain transaksi sering gagal di step akhir.
Kelemahan fundamental 2PC yang terungkap dari kasus ini dan alternatif yang lebih tepat adalah...
- A. 2PC adalah blocking protocol — coordinator failure atau slow participant menyebabkan seluruh sistem block; alternatif: Saga pattern dengan compensating transactions.
- B. 2PC terlalu cepat sehingga transaction selesai sebelum user selesai mengisi form.
- C. 2PC hanya bekerja dengan database relational, tidak dengan NoSQL.
- D. Seharusnya menggunakan Three-Phase Commit (3PC) yang selalu lebih superior.
- E. 2PC menjamin availability, bukan consistency.
Narasi Kasus: Platform social media dengan 100 juta user melakukan sharding database berdasarkan user_id. Setelah 2 tahun, beberapa shard menjadi "hot" (user selebriti dengan jutaan follower) sementara shard lain hampir kosong. Query yang melibatkan user dari shard berbeda menjadi sangat lambat.
Masalah mendasar dan solusi paling tepat untuk skenario ini adalah...
- A. Hash-based sharding selalu menyebabkan hot spot; solusi: gunakan consistent hashing dengan virtual nodes untuk distribusi lebih merata, dan pertimbangkan denormalisasi untuk query cross-shard.
- B. Sharding adalah konsep yang salah; seharusnya gunakan single database besar.
- C. Hot shard seharusnya dihapus dan user dipindahkan manual.
- D. Seharusnya menggunakan range-based sharding bukan hash-based.
- E. Cross-shard query tidak bisa dioptimasi, harus dihindari sepenuhnya.
Narasi Kasus: Aplikasi mobile banking menggunakan offline-first architecture dengan local database (SQLite) dan sync ke server saat online. Ketika user melakukan 5 transaksi offline, lalu online, terjadi conflict karena saldo di server sudah berubah akibat transaksi dari device lain.
Strategi conflict resolution paling tepat untuk sistem finansial seperti ini adalah...
- A. Last Write Wins (LWW) — transaksi terakhir yang menang.
- B. Server Wins — selalu prioritaskan state server, tolak transaksi offline yang conflict.
- C. Operational Transformation (OT) atau CRDTs dengan business rules khusus — untuk finansial, conflict harus di-resolve secara manual atau via compensating transaction karena tidak ada yang bisa di-drop.
- D. First Write Wins — transaksi offline pertama yang diproses.
- E. Hapus fitur offline untuk menghindari conflict.
Narasi Kasus: Smart city Bukittinggi mengimplementasikan 10.000 IoT sensor (traffic, lingkungan, CCTV). Semua data dikirim ke cloud untuk diproses. Bandwidth network kewalahan, latency untuk emergency response (kebakaran, kecelakaan) mencapai 8 detik — terlalu lambat.
Arsitektur paling tepat untuk mengatasi masalah ini adalah...
- A. Menambah bandwidth internet kota menjadi 10 Gbps.
- B. Three-tier edge-fog-cloud architecture: emergency processing di edge (latency < 100ms), analytics di fog layer, long-term storage dan ML training di cloud — mengurangi bandwidth 80% dan latency kritis.
- C. Mengurangi jumlah sensor menjadi 1.000.
- D. Memproses semua data di device sensor sendiri tanpa cloud.
- E. Menggunakan 5G untuk semua sensor — menyelesaikan semua masalah.
Narasi Kasus Integratif: Indonesia akan membangun "Sistem Kesehatan Nasional Terpadu" yang menghubungkan 10.000 faskes, 500 rumah sakit, 50 lab pusat, dengan requirement: (1) data pasien konsisten real-time, (2) tersedia 24/7 dengan RTO < 15 menit, (3) aman dari cyber attack, (4) compliant UU PDP, (5) mendukung offline untuk daerah 3T, (6) hemat energi (eco-friendly).
Arsitektur komprehensif manakah yang paling memenuhi semua requirement dengan trade-off paling rasional?
- A. Centralized cloud database dengan backup harian — paling sederhana dan murah.
- B. Hybrid architecture: edge node di setiap faskes (offline capability), fog layer di kabupaten (aggregation), cloud region di 5 lokasi (disaster recovery); data kritis menggunakan strong consistency, data historis eventual consistency; zero-trust security dengan encryption end-to-end; green data center dengan renewable energy.
- C. Full blockchain untuk semua data kesehatan — menjamin immutability dan transparency.
- D. Peer-to-peer murni tanpa server pusat — maksimal availability.
- E. Menggunakan 100% on-premise di setiap faskes tanpa cloud — paling aman secara data sovereignty.
✍️ Bagian B — Essay HOTS (5 Soal)
Kasus: Sebuah bank syariah di Sumatera Barat akan melakukan transformasi digital dengan membangun "Islamic Digital Banking Platform". Platform harus: (a) arsitektur microservices, (b) compliant dengan standar keamanan OJK dan Bank Indonesia, (c) di-deploy di cloud dengan pertimbangan data sovereignty, (d) mendukung prinsip green IT.
Rancanglah
arsitektur komprehensif yang mencakup:
- Diagram arsitektur microservices dengan boundary yang tepat (Bab 2)
- Strategi keamanan berlapis: authentication, authorization, encryption, audit trail (Bab 9)
- Pilihan cloud deployment model dengan justifikasi data sovereignty (Bab 12)
- Implementasi green IT: carbon-aware computing, efficient resource utilization (Bab 12)
Jelaskan trade-off dari setiap keputusan desain Anda!
[Ruang Jawaban — minimal 300 kata + diagram arsitektur]
Kasus: Platform e-commerce "PasarMinang" mengalami masalah saat flash sale: (1) stok produk tidak konsisten antara cache, database, dan search index, (2) service discovery gagal saat auto-scaling, (3) distributed transaction antara payment-inventory-shipping sering timeout.
Lakukan
root cause analysis untuk ketiga masalah tersebut dan usulkan solusi terintegrasi:
- Model konsistensi apa yang tepat untuk inventory saat flash sale? (Bab 6)
- Bagaimana memperbaiki service discovery untuk dynamic scaling? (Bab 10)
- Mengapa 2PC gagal dan apa alternatifnya? (Bab 13)
Jelaskan bagaimana ketiga solusi tersebut saling berinteraksi dalam arsitektur yang kohesif!
[Ruang Jawaban — analisis mendalam dengan referensi teori]
Kasus: Sistem IoT untuk pertanian presisi di dataran tinggi Bukittinggi: 5.000 sensor (suhu, kelembaban, pH tanah) di area dengan konektivitas internet tidak stabil. Data harus dikumpulkan, disimpan, dan dianalisis untuk rekomendasi pemupukan. Sistem harus tahan terhadap failure sensor, network partition, dan node failure.
Rancanglah
arsitektur end-to-end yang mencakup:
- Strategi fault tolerance untuk sensor dan network (Bab 7)
- Distributed file/storage system untuk time-series data sensor (Bab 11)
- Mobile/edge computing strategy untuk area dengan konektivitas terbatas (Bab 14)
Sertakan analisis: bagaimana sistem tetap berfungsi saat 30% sensor mati dan network ke cloud putus selama 6 jam?
[Ruang Jawaban — minimal 300 kata dengan diagram alur data]
Kasus: Sistem voting elektronik (e-voting) untuk pemilihan kepala daerah di Sumatera Barat. Requirement: (1) setiap suara tercatat exactly-once, (2) anonimitas pemilih terjaga, (3) hasil bisa diaudit publik, (4) tahan terhadap Byzantine fault (node malicious), (5) sinkronisasi waktu akurat untuk timestamp suara.
Bandingkan
dua pendekatan arsitektur untuk sistem ini:
- Pendekatan A: Distributed database tradisional dengan BFT consensus
- Pendekatan B: Blockchain-based dengan smart contract
Analisis kedua pendekatan dari perspektif:
- Sinkronisasi dan konsensus (Bab 5)
- Keamanan dan kriptografi (Bab 9)
- Transaksi dan konsistensi (Bab 13)
Berikan
rekomendasi final dengan justifikasi teoritis yang kuat!
[Ruang Jawaban — komparatif analysis minimal 400 kata]
Kasus: Anda ditunjuk sebagai
Chief Technology Architect untuk proyek nasional "Smart Island Sumatera Barat 2030". Proyek ini akan mendigitalisasi seluruh layanan publik, ekonomi, kesehatan, pendidikan, dan lingkungan di Sumatera Barat dengan 6 juta penduduk, 19 kabupaten/kota, topografi beragam (pantai, dataran tinggi, pulau).
Requirement Utama:
- Latensi < 200ms untuk layanan kritis
- Availability 99.99% untuk layanan essential
- Zero data loss untuk data vital (kesehatan, keuangan)
- Compliant UU PDP dan standar keamanan nasional
- Carbon-neutral operation (eco-friendly)
- Budget terbatas (harus cost-effective)
- Harus berfungsi di daerah dengan infrastruktur terbatas
Susunlah
Master Architecture Blueprint yang mengintegrasikan
minimal 10 konsep dari Bab 1-15:
- Visi dan prinsip arsitektur (Bab 1-2)
- Strategi komunikasi dan protokol (Bab 3-4)
- Sinkronisasi dan konsistensi (Bab 5-6)
- Fault tolerance dan disaster recovery (Bab 7)
- Keamanan dan privacy (Bab 9)
- Naming dan service discovery (Bab 10)
- Storage dan file system (Bab 11)
- Cloud dan deployment strategy (Bab 12)
- Data management dan database (Bab 13)
- Mobile, IoT, dan edge computing (Bab 14)
- Implementasi roadmap dan studi kasus referensi (Bab 15)
Sertakan pula
strategi eco-friendly: bagaimana sistem ini berkontribusi pada pengurangan emisi karbon dan keberlanjutan lingkungan Sumatera Barat!
[Ruang Jawaban — essay komprehensif minimal 500 kata, sertakan diagram high-level architecture]