24.3 Fondasi yang Tidak Bisa Ditawar

Bayangkan Anda sedang memimpin diskusi desain untuk sistem baru. Seorang engineer junior mengusulkan pendekatan yang kelihatan rapi di diagram, tapi Anda langsung melihat masalahnya: query yang dia usulkan akan memblokir tabel di database produksi selama beberapa detik. Anda tidak perlu membuka IDE untuk tahu itu masalah. Anda cukup membayangkan bagaimana database menangani transaksi, bagaimana locking bekerja, dan bagaimana antrean query mengalir. Pengetahuan itu datang dari pengalaman menulis code yang berinteraksi langsung dengan database.

Inilah yang dimaksud dengan fondasi yang tidak bisa ditawar. Sebagai arsitek, Anda tidak perlu coding delapan jam sehari. Tapi Anda harus tetap punya code proximity—kedekatan dengan code yang cukup untuk merasakan implikasi dari setiap keputusan desain. Tanpa ini, keputusan Anda akan seperti resep masakan dari orang yang belum pernah memegang pisau.

Apa saja fondasi itu? Pertama, programming. Bukan berarti Anda harus hafal sintaks semua bahasa, tapi Anda harus paham bagaimana code dieksekusi: bagaimana memori dialokasikan, bagaimana thread bekerja, bagaimana fungsi dipanggil, bagaimana data bergerak dari satu modul ke modul lain. Pengetahuan ini yang membuat Anda bisa memperkirakan biaya dari sebuah abstraksi atau memahami kenapa sebuah pendekatan yang terlihat elegan di slide ternyata lambat di produksi.

Kedua, data. Arsitek harus paham bagaimana data disimpan, diambil, dan diproses. Bukan hanya SQL, tapi juga konsep seperti indexing, partitioning, sharding, dan caching. Anda tidak perlu menjadi database administrator, tapi Anda harus bisa membaca query plan dan memperkirakan beban yang akan diterima database dari desain Anda. Ketika tim bertanya apakah perlu menambahkan indeks atau memisahkan tabel, Anda harus bisa memberikan jawaban berdasarkan pemahaman, bukan tebakan.

Ketiga, network. Banyak orang yang baru masuk ke peran arsitek mengabaikan ini karena network terasa seperti urusan infrastruktur. Padahal, hampir semua sistem modern berkomunikasi melalui network. Latency, bandwidth, timeout, retry, circuit breaker—ini bukan istilah yang hanya perlu dikenal, tapi harus dipahami dampaknya terhadap desain. Ketika Anda memutuskan bahwa service A akan memanggil service B secara sinkron, Anda harus bisa memperkirakan berapa lama waktu yang akan ditambahkan ke total response time.

Keempat, operating system. Bagaimana proses dijadwalkan, bagaimana memory management bekerja, bagaimana file system menangani I/O. Pengetahuan ini membantu Anda memahami kenapa sebuah aplikasi yang berjalan baik di laptop tiba-tiba lambat di server produksi. Bukan karena ada yang salah dengan code, tapi karena resource contention yang tidak terlihat di lingkungan lokal.

Kelima, database. Ini layak disebut terpisah dari data karena database adalah komponen yang paling sering menjadi bottleneck di sistem nyata. Seorang arsitek harus paham perbedaan antara relational database, document store, key-value store, dan graph database. Bukan untuk pamer istilah, tapi untuk memilih alat yang tepat. Dan yang lebih penting: paham trade-off antara consistency, availability, dan partition tolerance.

Kelima fondasi ini bukan untuk dihafal dari buku. Mereka harus dipraktikkan. Cara terbaik menjaganya tetap tajam adalah dengan sesekali turun tangan: ikut code review, membantu debugging masalah produksi, atau menulis prototype untuk menguji asumsi. Bukan sebagai pelaksana harian, tapi sebagai seseorang yang tetap menyentuh tanah.

Berikut diagram yang merangkum bagaimana kelima fondasi tersebut saling terhubung dan menghasilkan kemampuan inti seorang arsitek.

flowchart TD A[Programming] --> G[Code Proximity] B[Data] --> G C[Network] --> G D[Operating System] --> G E[Database] --> G G --> H[Kemampuan Membayangkan Implikasi Desain] A --> A1[Memory Allocation] A --> A2[Thread & Concurrency] B --> B1[Indexing & Query Plan] B --> B2[Partitioning & Sharding] C --> C1[Latency & Bandwidth] C --> C2[Timeout & Circuit Breaker] D --> D1[Process Scheduling] D --> D2[File I/O] E --> E1[Consistency vs Availability] E --> E2[Trade-off CAP Theorem]

Setelah fondasi ini kuat, barulah Anda bisa membangun di atasnya. Bahasa sehari-hari seorang arsitek bukan lagi syntax atau framework, melainkan software design dan distributed system. Mari kita lihat apa artinya itu.