Menavigasi Lanskap Teknologi Indonesia 2026: Antara Modular Monolith dan Gelombang AI
Beberapa tahun terakhir, kita melihat pergeseran yang cukup drastis dalam cara kita membangun perangkat lunak di Indonesia. Kalau dulu kita terobsesi dengan "skala" sampai-sampai banyak startup yang langsung melompat ke arsitektur microservices di hari pertama, tahun 2026 membawa kita pada sebuah realita yang berbeda: efisiensi adalah mata uang baru.
Saat ini, banyak tim engineering di Jakarta dan Bandung mulai merasakan apa yang bisa disebut sebagai "microservices hangover". Kompleksitas jaringan, biaya observabilitas yang membengkak, dan koordinasi antar-tim yang melelahkan membuat banyak dari kita mulai melirik kembali ke arah monolith—tapi bukan monolith yang berantakan, melainkan Modular Monolith.
Pendekatan modular monolith ini menarik karena memberikan kita batas-batas domain yang jelas (bounded contexts) seperti pada microservices, namun tetap berjalan dalam satu unit deployable. Kita mendapatkan kecepatan pengembangan dan kemudahan debugging, tanpa harus berurusan dengan latensi jaringan atau kegagalan RPC yang aneh. Bagi banyak perusahaan yang sedang mengoptimalkan biaya operasional, kembali ke modular monolith adalah keputusan strategis yang sangat masuk akal.
Namun, ketika sistem benar-benar harus didistribusikan, tantangan terbesarnya tetaplah konsistensi data. Di sinilah pemahaman tentang Saga Pattern menjadi krusial. Kita tidak bisa lagi mengandalkan transaksi dua fase (2PC) yang sinkron dan lambat. Pilihan antara Saga Choreography (desentralisasi melalui event) dan Saga Orchestration (central manager) bukan sekadar masalah teknis, tapi masalah trade-off antara fleksibilitas dan visibilitas. Untuk flow yang kompleks seperti sistem pembayaran atau pemesanan tiket, orchestration biasanya menjadi pemenang karena memudahkan kita melacak di mana sebuah transaksi tersangkut.
Di sisi lain, kita tidak bisa mengabaikan gelombang AI yang sudah bukan lagi sekadar "fitur tambahan". Integrasi AI di tahun 2026 telah bergeser dari sekadar memanggil API LLM menjadi pembangunan infrastruktur data yang lebih cerdas. Munculnya Vector Databases membawa konsep baru seperti HNSW (Hierarchical Navigable Small World) dan Vector Quantization ke dalam diskusi harian backend engineer.
Kini, tantangannya bukan lagi bagaimana menyimpan data, tapi bagaimana melakukan pencarian semantik yang efisien di atas jutaan vektor. Menggabungkan pencarian keyword tradisional (BM25) dengan semantic search melalui Reciprocal Rank Fusion (RRF) menjadi standar baru dalam membangun sistem informasi yang relevan. Bagi backend engineer yang terbiasa dengan PostgreSQL atau MongoDB, memahami bagaimana indeks vektor bekerja menjadi pembeda antara sekadar "pemakai API" dan seorang "system designer".
Melihat kondisi pasar kerja saat ini, permintaan terhadap peran Backend Engineer yang menguasai Go atau Node.js tetap tinggi, namun ekspektasinya telah berubah. Perusahaan tidak lagi mencari orang yang sekadar bisa menulis kode, tapi engineer yang bisa melakukan reasoning atas pilihan arsitekturnya. Apakah kita butuh Kafka untuk case ini? Apakah Redis cukup? Mengapa memilih PostgreSQL daripada MongoDB untuk modul ini?
Pada akhirnya, menjadi engineer yang relevan di tahun 2026 adalah tentang menjadi "T-shaped". Kita perlu memiliki pemahaman yang luas tentang berbagai pola sistem (System Design), namun memiliki kedalaman spesialisasi di satu atau dua area, entah itu dalam optimasi database, infrastruktur cloud, atau AI engineering.
Dunia teknologi bergerak cepat, tapi prinsip dasar engineering—simplicity, reliability, dan scalability—tetap tidak berubah. Pertanyaannya sekarang, apakah kita membangun sistem untuk memecahkan masalah bisnis, atau kita membangun sistem hanya karena pola tersebut sedang trending?
