Apa Itu Load Balancer? Penjelasan Lengkap tentang Distribusi Traffic Website dan Aplikasi

Apa Sebenarnya Fungsi Load Balancer

Load balancer adalah sebuah sistem—baik yang diimplementasikan dalam bentuk perangkat keras, perangkat lunak, maupun layanan cloud terkelola—yang berada di antara klien dan sekelompok server backend (sering disebut sebagai server pool, server farm, atau target group). Sistem ini menerima semua permintaan masuk dan mendistribusikannya ke server-server yang tersedia berdasarkan strategi yang telah ditetapkan. Dari sudut pandang klien yang mengirimkan permintaan, load balancer tidak dapat dibedakan dari aplikasi yang sebenarnya; klien terhubung ke satu alamat tunggal (biasanya berupa nama domain atau alamat IP) tanpa perlu mengetahui atau melihat berapa banyak server yang sebenarnya berada di balik alamat tersebut ataupun server mana yang pada akhirnya memproses permintaan tertentu.

Abstraksi inilah nilai inti yang diberikan oleh load balancer. Sistem ini memisahkan identitas layanan yang berhadapan dengan klien dari infrastruktur spesifik yang mengimplementasikannya. Server backend dapat ditambahkan untuk menangani peningkatan beban, dihapus untuk pemeliharaan, diganti setelah kegagalan, atau ditingkatkan ke versi baru—semuanya tanpa perlu diketahui oleh klien—karena load balancer tetap menyajikan satu titik kontak yang stabil di tengah berbagai perubahan yang terjadi di baliknya.

Selain fungsi dasar mendistribusikan permintaan, load balancer biasanya menjalankan beberapa tanggung jawab terkait yang sangat penting agar horizontal scaling (peningkatan kapasitas dengan menambah jumlah server) dapat benar-benar berjalan andal dalam praktiknya. Load balancer terus memantau kesehatan setiap server backend, secara otomatis mengeluarkan server yang mengalami kegagalan atau tidak merespons dari kumpulan server yang layak menerima traffic data, serta memasukkannya kembali setelah server tersebut pulih—sebuah fungsi yang akan dibahas lebih mendalam nanti dalam panduan ini. Banyak load balancer juga menangani terminasi SSL/TLS, yaitu mendekripsi lalu lintas HTTPS yang masuk sehingga server backend dapat berkomunikasi secara internal menggunakan HTTP biasa (tanpa enkripsi), yang pada gilirannya mengurangi beban komputasi pada setiap server backend. Load balancer sering kali menyediakan fitur pencatatan dan pemantauan pola traffic, sehingga memberikan visibilitas kepada operator mengenai volume permintaan, waktu respons, dan tingkat kesalahan di seluruh kumpulan server. Selain itu, dalam penerapan yang lebih canggih, load balancer dapat melakukan routing berbasis konten—memeriksa isi sebenarnya dari sebuah permintaan (seperti jalur URL, header, atau cookie) dan mengarahkannya ke kumpulan server khusus yang dirancang untuk menangani jenis permintaan tersebut, alih-alih sekadar menyebarkan seluruh traffic secara merata ke kumpulan server yang tidak dibedakan fungsinya.

Load Balancing Layer 4 vs. Layer 7

Salah satu perbedaan paling penting dalam load balancing—dan perbedaan yang memiliki konsekuensi praktis nyata terhadap kemampuan load balancer—adalah lapisan jaringan OSI tempat sistem tersebut beroperasi. Perbedaan ini biasanya digambarkan sebagai load balancing Layer 4 versus Layer 7, yang masing-masing mengacu pada lapisan transport (transport layer) dan lapisan aplikasi (application layer) dari model jaringan OSI.

Load balancing Layer 4 beroperasi pada lapisan transport, menangani koneksi TCP atau UDP tanpa memeriksa konten aktual dari data yang dikirimkan. Load balancer Layer 4 mengambil keputusan perutean semata-mata berdasarkan informasi yang tersedia dalam header lapisan jaringan dan transport—yaitu alamat IP sumber dan tujuan serta nomor port. Saat koneksi TCP baru masuk, load balancer Layer 4 memilih server backend berdasarkan algoritma yang telah dikonfigurasi, lalu meneruskan semua paket berikutnya dalam koneksi tersebut ke server backend yang sama; proses ini biasanya dilakukan tanpa membongkar atau memeriksa data aplikasi yang sebenarnya (seperti permintaan HTTP, kueri database, atau payload spesifik protokol lainnya).

Karena load balancing Layer 4 tidak perlu mengurai (parse) atau memahami protokol lapisan aplikasi, sistem ini ringan secara komputasi dan sangat cepat, serta mampu menangani volume koneksi yang sangat tinggi dengan penambahan latensi yang minimal. Sistem ini juga bersifat agnostik terhadap protokol dalam arti yang sesungguhnya—ia dapat melakukan load balancing untuk traffic berbasis TCP atau UDP apa pun, baik itu HTTP, protokol database, protokol biner kustom, maupun lainnya, karena sistem ini tidak perlu memahami detail spesifik dari data yang sedang dikirimkan.

Konsekuensinya, load balancing Layer 4 memiliki keterbatasan dalam hal pemahaman mengenai permintaan aktual yang melewatinya. Sistem ini tidak dapat mengambil keputusan perutean berdasarkan konten permintaan HTTP—seperti jalur URL yang diminta, cookie, header, atau badan permintaan (request body)—karena sistem ini tidak pernah memeriksa data tersebut. Ia tidak dapat membedakan antara permintaan API untuk `/api/users` dan permintaan untuk file video berukuran besar di `/media/movie.mp4`, meskipun kedua jenis permintaan tersebut mungkin akan lebih optimal jika diarahkan ke kumpulan server backend yang berbeda dan dirancang khusus untuk kebutuhan masing-masing.

Load balancing Layer 7 beroperasi pada lapisan aplikasi; artinya, sistem ini benar-benar mengurai dan memahami protokol aplikasi—yang paling umum adalah HTTP atau HTTPS—yang dibawa oleh koneksi TCP di bawahnya. Load balancer Layer 7 dapat melihat permintaan HTTP secara utuh, yaitu mulai dari metode (GET, POST, dan sebagainya), jalur URL, parameter kueri, header, cookie, hingga isi (body) permintaan. Kemampuan untuk melihat detail ini memungkinkan perutean berbasis konten, yaitu mengarahkan permintaan untuk `/api/*` ke kumpulan server aplikasi tertentu, permintaan untuk `/images/*` atau `/static/*` ke kumpulan server atau CDN yang dioptimalkan khusus untuk menyajikan aset statis, serta mengarahkan permintaan yang memuat nilai cookie tertentu ke versi aplikasi tertentu (berguna untuk canary deployment dan pengujian A/B).

Load balancer Layer 7 juga dapat melakukan pemeriksaan kesehatan yang lebih canggih (tidak sekadar memverifikasi apakah server menerima koneksi TCP, tetapi juga memastikan server memberikan respons HTTP yang benar terhadap endpoint pemeriksaan kesehatan tertentu), memodifikasi permintaan dan respons saat sedang diproses, mengompresi respons untuk menghemat bandwidth, serta menerapkan fitur yang memahami konteks aplikasi seperti pembatasan laju berdasarkan endpoint spesifik yang diakses. Konsekuensi dari kecerdasan tambahan ini adalah biaya komputasi, yaitu proses mengurai dan memeriksa seluruh konten lapisan aplikasi dari setiap permintaan membutuhkan daya pemrosesan lebih besar dibandingkan sekadar meneruskan paket berdasarkan alamat IP dan port. Akibatnya, meskipun sangat andal, load balancer Layer 7 umumnya menimbulkan latensi yang sedikit lebih tinggi dan membutuhkan sumber daya komputasi lebih besar per permintaan dibandingkan load balancer Layer 4 yang menangani volume lalu lintas serupa.

Dalam praktiknya, sebagian besar arsitektur aplikasi web modern menggunakan load balancing Layer 7 karena kemampuan perutean berbasis kontennya sangat berharga dan sepadan dengan beban tambahan yang ditimbulkannya. Selain itu, implementasi load balancer Layer 7 modern (seperti NGINX, HAProxy, AWS Application Load Balancer, dan lainnya) sudah cukup efisien untuk menangani volume traffic yang sangat besar tanpa menjadikan beban tambahan tersebut sebagai hambatan praktis bagi sebagian besar aplikasi. Load balancing Layer 4 tetap penting untuk protokol non-HTTP serta untuk skenario yang menuntut latensi serendah mungkin dan throughput mentah setinggi mungkin.

Penjelasan tentang Algoritma Load Balancing

Setelah load balancer menentukan bahwa suatu permintaan perlu diarahkan ke salah satu dari beberapa server backend yang tersedia, sistem tersebut memerlukan algoritma khusus untuk memutuskan server mana yang tepat. Setiap algoritma memiliki karakteristik dan pertimbangan yang berbeda, sehingga memilih algoritma yang tepat untuk beban kerja tertentu merupakan keputusan arsitektur yang krusial.

Round robin adalah algoritma yang paling sederhana dan paling banyak digunakan, yaitu load balancer mengalirkan permintaan melalui daftar server yang tersedia secara berurutan—mengirimkan permintaan pertama ke server satu, permintaan kedua ke server dua, permintaan ketiga ke server tiga, dan seterusnya—lalu kembali ke awal daftar setelah mencapai akhir. Round robin mudah diterapkan dan bekerja dengan baik jika semua server backend memiliki kapasitas yang kurang lebih sama serta setiap permintaan memberikan beban kerja yang relatif setara bagi server yang memprosesnya. Keterbatasannya adalah algoritma ini tidak memperhitungkan beban aktual saat ini ataupun status kesehatan masing-masing server; server yang sedang memproses permintaan yang sangat berat tetap akan menerima permintaan berikutnya sesuai jadwal, yang berpotensi memperparah beban kerja yang sudah tinggi pada server tersebut.

Weighted round robin mengembangkan pendekatan round robin dasar dengan memberikan nilai bobot pada setiap server yang mencerminkan kapasitas relatifnya, lalu mendistribusikan permintaan secara proporsional berdasarkan bobot tersebut. Server yang memiliki kapasitas CPU dan memori dua kali lipat dibandingkan server lain dalam kumpulan tersebut dapat diberi bobot dua; ini berarti server tersebut akan menerima jumlah permintaan dua kali lebih banyak dalam setiap siklus rotasi. Pendekatan ini mengatasi asumsi kapasitas setara pada round robin dasar, sehingga memungkinkan kumpulan server yang heterogen—situasi umum saat peningkatan infrastruktur, di mana server baru yang lebih tangguh ditambahkan bersama server lama—untuk mendapatkan distribusi beban yang proporsional dengan kemampuan aktual masing-masing server.

Metode least connections menerapkan pendekatan yang secara mendasar berbeda dan lebih dinamis, yaitu alih-alih mengikuti rotasi tetap, load balancer memantau jumlah koneksi aktif yang sedang ditangani oleh setiap server backend dan mengarahkan setiap permintaan baru ke server yang saat itu memiliki jumlah koneksi aktif paling sedikit. Algoritma ini memperhitungkan kenyataan bahwa tidak semua permintaan membutuhkan waktu pemrosesan yang sama—server yang sedang menangani beberapa permintaan berdurasi panjang secara alami akan menerima lebih sedikit permintaan baru hingga koneksi-koneksi tersebut selesai, sehingga menghasilkan distribusi beban aktual yang jauh lebih merata dibandingkan rotasi posisi sederhana pada metode round robin.

Metode weighted least connections menggabungkan kedua gagasan sebelumnya dengan memperhitungkan bobot kapasitas yang ditetapkan bagi server serta jumlah koneksi aktifnya saat ini dalam pengambilan keputusan perutean; tujuannya adalah mendapatkan gambaran paling akurat mengenai kapasitas aktual yang tersedia di dalam kumpulan server yang heterogen.

Metode IP hash menghitung nilai hash dari alamat IP klien (terkadang dikombinasikan dengan alamat tujuan) dan menggunakan nilai hash tersebut untuk menentukan secara konsisten server backend mana yang akan menerima permintaan dari klien tertentu. Karena IP klien yang sama akan selalu menghasilkan nilai hash yang sama, pendekatan ini secara alami menciptakan bentuk persistensi sesi, yaitu klien yang sama akan secara konsisten diarahkan ke server backend yang sama untuk berbagai permintaan terpisah, tanpa load balancer perlu menyimpan status sesi secara eksplisit. Metode ini sangat berguna bagi aplikasi yang menyimpan data sesi secara lokal di server spesifik yang pertama kali menangani permintaan pengguna, meskipun metode ini memiliki keterbatasan nyata, terutama bagi klien yang berada di balik gateway NAT perusahaan bersama atau jaringan seluler; dalam situasi tersebut, banyak pengguna berbeda dapat terlihat berasal dari alamat IP yang sama, sehingga berpotensi memusatkan beban yang tidak proporsional pada server yang menjadi tujuan hash dari IP bersama tersebut.

Metode least response time (yang terkadang diterapkan dalam varian weighted response time) mengarahkan permintaan baru ke server yang saat ini memiliki latensi respons terendah; pada beberapa implementasi, metode ini dikombinasikan dengan logika least-connections. Pendekatan ini secara langsung mengoptimalkan kinerja aktual yang dirasakan oleh klien dan beradaptasi secara dinamis saat server tertentu mengalami perlambatan sementara—misalnya akibat jeda garbage collection, tugas latar belakang, atau gangguan kinerja sesaat lainnya—namun konsekuensinya, load balancer harus terus-menerus mengukur dan memantau data waktu respons untuk setiap server dalam kumpulan tersebut.

Pemilihan secara acak maupun acak berbobot —meskipun mungkin tampak berlawanan dengan intuisi—ternyata menunjukkan kinerja yang sangat baik dalam praktik untuk kumpulan server besar dengan volume permintaan tinggi. Sifat statistik dari pemilihan acak pada banyak permintaan cenderung menghasilkan distribusi yang cukup merata tanpa beban komputasi tambahan untuk melacak jumlah koneksi atau waktu respons, sehingga menjadikannya pilihan menarik untuk skenario yang sangat sensitif terhadap latensi dan memiliki throughput yang sangat tinggi.

Pemeriksaan Kesehatan dan Deteksi Kegagalan

Load balancer yang terus mengirimkan traffic ke server backend yang telah mati (crash), tidak merespons, atau menghasilkan error tidak memberikan manfaat nyata dibandingkan tanpa load balancer sama sekali; bahkan lebih buruk lagi, sistem ini secara aktif mengarahkan sebagian permintaan klien menuju kegagalan yang pasti terjadi. Pemeriksaan kesehatan adalah mekanisme yang digunakan load balancer untuk terus memverifikasi bahwa setiap server backend dalam pool-nya benar-benar mampu menangani permintaan dengan baik, serta secara otomatis menyesuaikan perutean untuk mengecualikan server yang tidak mampu melakukannya.

Pemeriksaan kesehatan pasif memantau traffic aktual yang mengalir melalui load balancer secara real-time, melacak hasil dari permintaan nyata yang dikirim ke setiap server backend—mencatat kegagalan koneksi, timeout koneksi, dan respons error saat hal-hal tersebut terjadi secara alami. Jika tingkat kegagalan server pada traffic nyata melampaui ambang batas yang telah dikonfigurasi dalam jangka waktu tertentu, load balancer akan menandai server tersebut sebagai tidak sehat (unhealthy) dan berhenti mengarahkan traffic baru ke server tersebut. Pemeriksaan pasif memiliki keunggulan dalam mencerminkan perilaku server yang sebenarnya di bawah kondisi produksi nyata, namun secara inheren memerlukan sejumlah permintaan klien nyata yang gagal sebelum masalah terdeteksi; ini berarti setidaknya sebagian pengguna akan mengalami kegagalan tersebut sebelum sistem bereaksi.

Pemeriksaan kesehatan aktif mengambil pendekatan yang lebih proaktif, yaitu load balancer secara mandiri dan terus-menerus mengirimkan permintaan uji sintetis ke setiap server backend sesuai jadwal rutin (biasanya setiap beberapa detik), sepenuhnya terlepas dari traffic klien yang sebenarnya. Untuk pengaturan Layer 4 yang sederhana, hal ini bisa sesederhana mencoba membuka koneksi TCP ke port tertentu dan memverifikasi bahwa server menerimanya. Untuk pengaturan Layer 7 yang lebih canggih, proses ini biasanya melibatkan pengiriman permintaan HTTP aktual ke endpoint pemeriksaan kesehatan khusus (umumnya seperti `/health` atau `/healthz`) yang disediakan aplikasi khusus untuk tujuan ini, serta memverifikasi bahwa server merespons dengan kode status yang diharapkan (biasanya `200 OK`) dalam batas waktu yang wajar.

Endpoint pemeriksaan kesehatan yang dirancang dengan baik melakukan lebih dari sekadar memastikan bahwa proses server web sedang berjalan dan menerima koneksi; endpoint pemeriksaan kesehatan yang benar-benar bermanfaat memverifikasi bahwa dependensi kritis aplikasi memang berfungsi, yaitu seperti aplikasi dapat terhubung ke database-nya, layanan hilir yang diperlukan dapat diakses, dan kondisi lain yang dibutuhkan server untuk menangani permintaan nyata dengan benar telah terpenuhi. Pemeriksaan kesehatan yang hanya memastikan "proses sedang berjalan"—sementara koneksi database aplikasi sebenarnya terputus tanpa disadari—akan melaporkan server dalam kondisi sehat hingga saat permintaan pengguna nyata gagal; hal ini menggagalkan sebagian besar tujuan praktis diadakannya pemeriksaan kesehatan itu sendiri.

Session Persistence dan Sticky Session

Banyak aplikasi—terutama aplikasi lama atau yang menangani jenis interaksi stateful tertentu—memerlukan agar rangkaian permintaan dari pengguna tertentu secara konsisten diarahkan ke server backend yang sama, alih-alih didistribusikan secara bebas ke seluruh kumpulan server pada setiap permintaan individu. Kebutuhan ini paling umum disebut sebagai session persistence atau, dalam istilah yang lebih umum digunakan, sticky session.

Kebutuhan mendasar ini biasanya muncul ketika aplikasi menyimpan data spesifik sesi—seperti keranjang belanja, formulir multi-tahap yang sedang diisi, atau token sesi terautentikasi—di dalam memori proses server tertentu yang pertama kali menangani pengguna tersebut, dan bukan di penyimpanan data terpusat yang dapat diakses secara setara oleh semua server backend. Jika permintaan kedua pengguna diarahkan ke server berbeda yang tidak memiliki informasi mengenai data sesi yang tersimpan di server pertama, aplikasi mungkin akan berperilaku tidak semestinya: misalnya, keranjang belanja pengguna tampak kosong, pengguna tiba-tiba logged out, atau status operasi yang sedang berlangsung hilang.

Load balancer menerapkan session persistence melalui beberapa mekanisme umum. Persistensi berbasis cookie adalah pendekatan yang paling banyak digunakan untuk load balancer Layer 7, yaitu load balancer menyisipkan cookie ke dalam respons yang dikirim kembali ke klien untuk mengidentifikasi server backend spesifik yang menangani permintaan klien tersebut; pada semua permintaan berikutnya, load balancer membaca cookie ini dan mengarahkan permintaan ke server yang sama dengan yang telah diidentifikasi sebelumnya. Persistensi berbasis IP sumber menggunakan alamat IP klien sebagai kunci persistensi (secara fungsional mirip dengan algoritma IP hash yang dibahas sebelumnya), dengan mengarahkan semua permintaan dari IP sumber yang sama ke server backend yang sama; namun, pendekatan ini memiliki keterbatasan yang telah disebutkan sebelumnya terkait klien yang berbagi alamat IP di balik NAT.

Meskipun session persistence mengatasi masalah langsung terkait server stateful, perlu dicatat bahwa dari perspektif desain sistem, hal ini secara umum dianggap bertentangan dengan beberapa manfaat utama yang ingin dicapai melalui horizontal scaling dan load balancing. Kumpulan server dengan fitur sticky session yang aktif lebih rentan terhadap distribusi beban yang tidak merata (karena sejumlah kecil pengguna yang sangat aktif dapat memusatkan beban yang tidak proporsional pada server spesifik tempat mereka terikat) serta gangguan saat server tertentu harus dimatikan untuk pemeliharaan atau mengalami kegagalan tak terduga (karena setiap pengguna yang sesinya terikat pada server tersebut akan kehilangan status sesi mereka). Oleh karena itu, pola arsitektur modern yang sangat disarankan adalah merancang aplikasi agar benar-benar stateless di tingkat server individu—dengan menyimpan data sesi di penyimpanan eksternal bersama seperti Redis atau database yang dapat diakses secara setara oleh setiap server backend—sehingga menghilangkan kebutuhan akan sticky session sepenuhnya dan memungkinkan load balancer mendistribusikan setiap permintaan secara bebas, yang pada akhirnya memaksimalkan distribusi beban yang merata sekaligus ketahanan terhadap kegagalan server individu.

Load Balancer Berbasis Perangkat Keras, Software, dan Cloud

Load balancer berbasis perangkat keras adalah perangkat fisik khusus—seperti produk dari vendor F5 Networks dan Citrix—yang dirancang dengan perangkat keras khusus yang dioptimalkan untuk memproses traffic dengan throughput sangat tinggi. Secara historis, perangkat ini merupakan standar di pusat data perusahaan besar sebelum komputasi cloud mendominasi, karena menawarkan performa mentah yang sangat tinggi serta kapasitas yang khusus dan dapat diprediksi. Namun, perangkat ini memiliki kekurangan yang signifikan dalam konteks modern, yaitu biaya modal awal yang tinggi, batasan kapasitas fisik tetap (yang mengharuskan pembelian dan pemasangan fisik perangkat keras tambahan untuk meningkatkan kapasitas), serta beban operasional terkait pengelolaan, pemeliharaan, dan penggantian perangkat fisik tersebut.

Load balancer berbasis software berjalan sebagai proses software pada server komoditas standar tanpa memerlukan perangkat keras khusus, sehingga menawarkan fleksibilitas yang jauh lebih besar dan biaya yang jauh lebih rendah. NGINX dan HAProxy adalah dua load balancer software open-source yang paling banyak digunakan; keduanya mampu memberikan performa sangat tinggi serta mendukung logika perutean Layer 7 yang canggih, pemeriksaan kesehatan, dan terminasi SSL. Envoy Proxy, yang awalnya dikembangkan oleh Lyft, telah menjadi sangat populer dalam arsitektur cloud-native dan service mesh modern berkat fitur observabilitasnya yang kuat serta perannya sebagai implementasi data plane standar yang mendasari sistem service mesh populer seperti Istio.

Load balancer cloud adalah layanan load balancing yang dikelola sepenuhnya dan ditawarkan langsung oleh penyedia layanan cloud; pengguna tidak perlu melakukan penyediaan server, instalasi software, ataupun pemeliharaan apa pun, karena infrastruktur dasar, penskalaan, dan sebagian besar beban operasional ditangani sepenuhnya oleh penyedia cloud. AWS menawarkan beberapa jenis load balancer berbeda yang disesuaikan dengan berbagai kebutuhan, yaitu seperti Application Load Balancer (ALB) untuk traffic HTTP/HTTPS Layer 7 dengan perutean berbasis konten, Network Load Balancer (NLB) untuk traffic TCP/UDP Layer 4 dengan performa sangat tinggi, serta Gateway Load Balancer untuk penerapan dan penskalaan perangkat keamanan jaringan pihak ketiga. Google Cloud dan Microsoft Azure menawarkan layanan load balancing terkelola yang sebanding di platform masing-masing. Keunggulan utama load balancer cloud adalah kemampuannya menghilangkan hampir seluruh beban operasional dalam menjalankan dan menskalakan lapisan load balancing itu sendiri—dengan menangani penskalaan internal secara otomatis seiring meningkatnya traffic serta berintegrasi erat dengan ekosistem penyedia lainnya (seperti grup auto-scaling, pemantauan kesehatan, manajemen sertifikat, dan sebagainya)—namun hal ini disertai dengan biaya rutin berdasarkan penggunaan serta adanya tingkat konfigurasi dan ketergantungan tertentu pada vendor (vendor lock-in).

Penyeimbangan Beban dan Distribusi Global

Segala hal yang telah dibahas sejauh ini berfokus pada distribusi traffic di antara sekelompok server yang biasanya berada dalam satu pusat data atau satu wilayah geografis. Namun, aplikasi yang melayani basis pengguna yang benar-benar global menghadapi lapisan tambahan dari masalah dasar yang sama, yaitu pengguna di Singapura yang mengirim permintaan ke pusat data di Virginia akan mengalami latensi yang jauh lebih tinggi—semata-mata karena jarak fisik yang harus ditempuh oleh permintaan dan respons tersebut—dibandingkan dengan pengguna yang memang berada di dekat Virginia. Penyeimbangan beban global (terkadang disebut global server load balancing atau GSLB) mengatasi hal ini dengan mendistribusikan traffic tidak hanya ke beberapa server di satu lokasi, tetapi ke berbagai wilayah geografis yang sepenuhnya terpisah; idealnya, sistem ini mengarahkan permintaan setiap pengguna ke wilayah yang paling dekat dengan mereka atau wilayah yang paling mampu melayani mereka dengan optimal.

Mekanisme praktis yang paling umum digunakan untuk menerapkan penyeimbangan beban global adalah perutean berbasis DNS. Alih-alih menggunakan satu catatan DNS yang menerjemahkan nama domain menjadi satu alamat IP tetap, sistem penyeimbangan beban global berbasis DNS menerjemahkan nama domain yang sama menjadi alamat IP yang berbeda-beda tergantung pada asal kueri DNS tersebut. Sistem ini mengarahkan klien peminta ke penyebaran wilayah spesifik yang paling dekat atau paling sesuai untuk melayani mereka berdasarkan kebijakan perutean yang telah dikonfigurasi. Layanan seperti AWS Route 53, Cloudflare, dan Google Cloud DNS menawarkan kemampuan penyeimbangan beban global berbasis DNS yang canggih semacam ini, serta mendukung berbagai kebijakan perutean, yaitu perutean berbasis latensi (mengarahkan traffic ke wilayah yang saat itu menawarkan latensi terukur terendah bagi pengguna tertentu), perutean berbasis geolokasi (mengarahkan traffic berdasarkan asal geografis permintaan, yang terkadang diperlukan karena alasan regulasi atau lisensi konten, bukan semata-mata demi kinerja), dan perutean berbobot (membagi traffic ke beberapa wilayah berdasarkan persentase yang telah dikonfigurasi, yang umum digunakan untuk peluncuran bertahap atau distribusi beban berbasis kapasitas).

Jadi pada dasarnya, load balancer merupakan konsep yang tampak sederhana namun memiliki kedalaman teknis yang signifikan di baliknya, yaitu sebuah sistem yang berada di antara klien dan kumpulan server backend, yang mendistribusikan permintaan masuk ke seluruh kumpulan tersebut berdasarkan strategi yang telah ditetapkan, memantau kesehatan setiap server secara berkelanjutan, serta secara otomatis mengeluarkan server yang bermasalah dari rotasi.