Fallacy #3: Bandwith isn't a problem

Bandwith merupakan hal yang sulit di ukur dari sisi perspektif coding dibandingkan dengan latency. Bandwith memang sangat berkembang pesat. Tetapi data yang berkembang jauh lebih cepat ketimbang bandwith itu sendiri. Tidak banyak developer yang sadar mengenai hal ini. Hal ini sangat sering sekali diabaikan. Dan hal ini sangat vital sekali di dalam performance dari aplikasi kita.

Network engineer berbicara tentan bit dan software engineer berbicara tentang bytes. GigaBit sama dengan 1028 Mb/s. Ini adalah raw ethernet. Jika kita berbicara tentang TCP/IP maka kita akan kehilangan setengah nya. Serialization, JSON, Protobuf, kita akan kehilangan setengah lagi. 300 mb/s. Kebanyakan orang akan memberikan solusi membuat lebih banyak server di dalam satu network yang sama. Kebanyakan kasus menambahkan lebih banyak server tidak akan memberikan solusi yang kita inginkan. Hanya akan menambah masalah lebih buruk.

Lebih banyak trafic yang datang, maka akan lebih banyak kemungkinan dari TCP packet retry. Hal ini akan membuat apikasi lebih lambat lagi. Dan hal ini akan berhubungan kembali dengan latency dan kemudian ke timeout.

Semakin lama data semakin berkembang sangat pesat sehingga perkembangannya lebih cepat dari bandwith yang kita miliki. Hal ini terbukti kebenarannya seperti service yang disediakan amazon atau cloud provider lain nya. Dimana kita dapat mengirimkan hard drive ke amazon atau cloud provider untuk di copy ke sana. Karena melalui network akan memakan waktu yang lebih lama dibandingkan memaketkannya.

Terlihat bertolak belakang dengan konsep melakukan loading data secara menyeluruh. Dimana kita membatasi data yang kita lewatkan dari network. Jadi mana yang benar ? Eagerly Fetch or Lazy Load ?

Jadi solusi yang terbaik adalah membuat domain model kita lebih spesific sehingga kita tidak perlu melakukan load semua object graph tetapi terbatas pada domain tertentu saja. Domain model tersebut hanya khusus untuk menangani skenario yang spesifik. Sehingga domain model tersebut dapat di fetch secara menyeluruh.

Dengan adanya keterbatasan bandwith ini kita diharapkan semakin pintar dalam melakukan dekomposisi dari domain model dan system kita. Sehingga tidak semua bagian system dibutuhkan dalam setiap interaksi dari user.

Hal lain yang dapat kita lakukan adalah membagi network menjadi high priiority network dan low priority network. Hal ini memudahkan kita untuk membagi-bagi request yang datang. Tetapi hal ini lagi membutuhkan kita untuk melakukan dekomposisi dengan benar.

Ibaratkan kita memiliki satu service dengan 2 method yaitu generate report dan mark as fraud di customer service. Jika kita bertanya ke user bisnis mengenai mana yang lebih prioritas tentu saja mereka memiliki mark as fraud. Dengan keputusan ini kita dapat memisahkan API tersebut menjadi 2 service yang lebih granular. Satu diletakkan di high priority network yaitu mark as fraud dan yang satu lagi ditempatkan di low priority network yaitu untuk generate report.

Berdasarkan penjelasan di atas maka kita dapat menyimpulkan jika kita menganalisa service layer ataupun API kita maka kita dapat membagi-bagi API tersebut menjadi API yang menjadi prioritas bisnis lebih tinggi. Jadi kita tidak lagi membagi API kita berdasarkan entity tetapi lebih ke prioritas masing-masing method atau fungsionalitas dari API tersebut.

Jadi anda sudah sadar manfaat membagi-bagi service atau API menjadi dekomposisi logical bukan ? Banyak kebutuhan yang dapat ditangani dengan aplikasi terdistribusi dan mungkin saja tidak dapat ditangani jika kita membuat system secara monolitik.