Application Scaling

Application Scaling

1. Scaling vertical => upgrade hardware
2. Scaling horizontal => tambah node dan tambah load balancer. Perlu diingat scaling secara horizontal aplikasi kita harus stateless, artinya aplikasi kita tidak menyimpan data, diusahkan di simpan di DB.
3. Teknologi non-blocking => saat buat aplikasi initinya I/O. Membuat rata-rata aplikasi basisnya thread / thread pool. saat aplikasi nyala biasanya dibuat beberapa thread 10 atau 100, sedangkan operasi input / output itu blocking dan harus ditunggu. Akhirnya thread yg dibuat jadi blocking. Dengan teknologi unblocking maka terima request sebanyak apapun.

4. Teknology ReactiveX tidak semudah yg dibayangkan, tidak semua framework dan library masih blocking, krn by default ketika kita buat aplikasi nonblocking dia akan membuat thread /worker. Kebnykan g bnyak yaitu 2 processor. Problemnya jika pakai library yg blocking dengan limit 2 processor, ini membuat workernya diblock oleh library yg masih blocking. Standard aplikasi di semua bhs programan , yaitu membeda-bedakan worker di tiap process yg kita inginkan contohnya worker utk process web, bisnis logic, dan database. Dengan adanya reactiveX ini saat ada bagian yg sedang sibuk fitur yg lain tidak kena impact nya.

5. Split aplikasi
contohnya emmorce yaitu searching product, yg butuh di scale tetap tidak diapa2 kan yg butuh di scale itu dibuat aplikasi yang baru. Setelah itu dibikin pake nonblocking atau reactiveX, tpi somehow dengan displit sebagian kecil lebih enak.

6. Scaling database
Kita harus pastikan yg bermasalah dimana.
Query lambat, normalisasi data
7. gunakan tool bantuan
Setiap documentasi framework itu punya tool tambahan ketika production supaya lebih bagus, contoh ruby dia di production menggunakan passanger, express js awalnya single thread maka di production akan running di beberapa process dan berjalan dalam 1 node/server. Artinya dlm production harus disesuaikan dengan setup yg sesuai dengan dokumentasi productionnya.
8. Optimize code program
Membuat logic sesederhana mungkin
performa aplikasi tidak bagus, maka bagian mana yg buruk (method, api). Buat code optimize tidak begitu readable, tetpi daripada lambat.
9. Aggressive caching
Dimana pun process yg lambat usahakan caching dlu.
misal nembak process lain , hasilnya kita cache dulu. atau misal kita process kalkulasi lama, kita bisa cache hasilnya
10. Tidak usah dipikirkan
Fokus pertama selesaikan aplikasinya dulu jika kita belum tau seberapa besar traffic dan usernya. Usahakan scaling nanti aja ketika sudah deliverd, performa aplikasi buruk baru scaling