API menjadi salah satu komponen penting dalam pengembangan aplikasi modern. Melalui API, aplikasi dapat saling bertukar data dan menjalankan fungsi tertentu tanpa harus berkomunikasi secara langsung dengan seluruh sistem di belakangnya. Namun, semakin banyak aplikasi yang mengakses sebuah API, semakin besar pula beban yang harus ditangani oleh server.

Tanpa mekanisme pengendalian, sebuah client dapat mengirim request dalam jumlah sangat banyak dalam waktu singkat. Kondisi tersebut dapat meningkatkan penggunaan resource server, memperlambat respons API, bahkan menyebabkan layanan tidak dapat melayani pengguna lain dengan baik. Salah satu mekanisme yang dapat digunakan untuk mengatasi masalah tersebut adalah rate limiting.

Rate limiting memungkinkan pengelola API menetapkan batas jumlah request yang dapat dilakukan oleh client dalam periode tertentu. Dengan cara ini, traffic dapat dikendalikan agar penggunaan resource tetap berada dalam batas yang wajar.

Apa Itu Rate Limiting?

Rate limiting adalah mekanisme untuk membatasi jumlah request yang dapat dikirim oleh client ke sebuah API dalam periode waktu tertentu.

Sebagai contoh, sebuah API dapat menetapkan aturan bahwa satu client hanya boleh mengirim maksimal 100 request per menit. Jika client mengirim request melebihi batas tersebut, server dapat menolak request tambahan hingga periode pembatasan berakhir.

Rate limiting tidak selalu berarti request yang melebihi batas langsung diblokir secara permanen. Umumnya, client hanya perlu menunggu sampai batas penggunaan kembali tersedia. Misalnya:

batas API: 100 request per menit;
request yang sudah digunakan: 100;
request ke-101: ditolak atau ditunda;
setelah window berikutnya: client dapat kembali mengirim request.

Mekanisme ini membantu API menjaga penggunaan resource agar tetap terkendali, terutama ketika layanan diakses oleh banyak pengguna atau aplikasi secara bersamaan.

Mengapa Rate Limiting Penting untuk API?

API biasanya menjadi pintu masuk menuju berbagai resource dan fungsi aplikasi. Jika tidak memiliki pembatasan, client yang melakukan request secara berlebihan dapat memengaruhi performa sistem secara keseluruhan.

Rate limiting memiliki beberapa fungsi penting.

Mencegah Request Berlebihan

Client yang mengalami bug dapat mengirim request secara berulang tanpa sengaja. Misalnya, sebuah aplikasi melakukan retry tanpa jeda ketika API gagal memberikan respons.

Jika tidak dibatasi, request tersebut dapat terus bertambah dan membebani server. Rate limiting memberikan batas sehingga jumlah request tetap terkendali.

Melindungi Resource Server

Setiap request membutuhkan resource seperti CPU, memory, koneksi database, bandwidth, atau layanan eksternal.

Ketika request meningkat secara drastis, penggunaan resource juga dapat meningkat. Rate limiting membantu mencegah satu client menggunakan resource secara tidak proporsional.

Mengurangi Risiko Abuse

API publik dapat menjadi target berbagai bentuk penyalahgunaan, seperti automated request, scraping berlebihan, brute-force terhadap endpoint tertentu, atau aktivitas lain yang menghasilkan traffic tidak wajar.

Rate limiting bukan satu-satunya lapisan keamanan yang dibutuhkan, tetapi dapat menjadi salah satu mekanisme mitigasi untuk membatasi volume request.

Menjaga Ketersediaan Layanan

Ketika traffic dikendalikan, server memiliki kesempatan lebih besar untuk tetap melayani pengguna lain.

Hal ini penting terutama untuk API yang digunakan oleh banyak aplikasi atau menyediakan layanan yang bersifat kritis.

Menerapkan Fair Usage

Rate limiting dapat digunakan untuk memastikan setiap client memperoleh akses secara lebih terkontrol.

Misalnya, API menetapkan batas yang sama untuk setiap API key sehingga satu aplikasi tidak dengan mudah menghabiskan seluruh kapasitas layanan.

Bagaimana Cara Kerja Rate Limiting?

Secara sederhana, rate limiting bekerja dengan menghitung jumlah request dari client berdasarkan aturan tertentu. Ketika request masuk, sistem akan menentukan identitas client dan memeriksa jumlah request yang sudah dilakukan dalam periode tertentu.

Alur sederhananya dapat digambarkan sebagai berikut:
Client → API Gateway/Server → Rate Limiter → Pemeriksaan Limit → API Endpoint

Jika jumlah request masih berada di bawah batas, request diteruskan ke endpoint.

Jika jumlah request sudah melebihi batas, sistem dapat mengembalikan response seperti HTTP 429 Too Many Requests. Contohnya:

Client
   |
   v
API Request
   |
   v
Rate Limiter
   |
   +---- Limit tersedia ----> API Endpoint ----> Response
   |
   +---- Limit terlampaui --> HTTP 429

Dalam implementasi nyata, rate limiter dapat ditempatkan di beberapa lapisan, seperti API gateway, reverse proxy, load balancer, application server, atau service tertentu.

Contoh Rate Limiting Sederhana

Misalnya sebuah API menyediakan endpoint: GET /api/products

Pengelola API menetapkan aturan: 100 request / menit / API key

Jika sebuah API key melakukan 80 request dalam satu menit, request tersebut masih berada dalam batas. Namun, ketika jumlah request mencapai 100, request berikutnya dapat ditolak sampai window berikutnya.

Contohnya:

Request	Status
Request 1–99	Diterima
Request 100	Diterima
Request 101	Dapat ditolak
Setelah window berikutnya	Limit tersedia kembali

Dalam API yang dirancang dengan baik, response juga dapat memberikan informasi kepada client mengenai status limit melalui response header. Contohnya:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 20

Header tersebut menunjukkan bahwa client memiliki batas 100 request dan masih memiliki 20 request yang tersedia dalam window tersebut.

Implementasi header dapat berbeda-beda tergantung API atau gateway yang digunakan.

Jenis-Jenis Rate Limiting

Rate limiting dapat diterapkan menggunakan beberapa algoritma. Masing-masing memiliki karakteristik berbeda dalam mengatur request.

1. Fixed Window

Fixed window membatasi request berdasarkan interval waktu yang sudah ditentukan.

Misalnya:

100 request / 1 menit

Sistem membagi waktu menjadi window tertentu, misalnya:

10:00:00 – 10:00:59
10:01:00 – 10:01:59
10:02:00 – 10:02:59

Setiap window memiliki counter sendiri.

Contohnya, client dapat mengirim 100 request pada pukul 10:00:50 dan kembali mengirim 100 request pada pukul 10:01:00.

Kelebihan dan kekurangannya:

Aspek	Fixed Window
Implementasi	Relatif sederhana
Performa	Ringan
Penggunaan memory	Relatif kecil
Risiko burst	Ada
Cocok untuk	API sederhana dan kebutuhan umum

Masalah yang perlu diperhatikan adalah boundary burst. Client dapat mengirim banyak request di akhir satu window dan kembali mengirim banyak request di awal window berikutnya.

2. Sliding Window

Sliding window menggunakan periode waktu yang bergerak mengikuti waktu request.

Misalnya aturan yang diterapkan adalah: 100 request dalam 60 detik terakhir

Ketika request baru masuk, sistem melihat jumlah request yang terjadi selama 60 detik sebelumnya. Metode ini dapat memberikan kontrol yang lebih halus dibandingkan fixed window, meskipun implementasinya dapat lebih kompleks.

Aspek	Sliding Window
Akurasi kontrol	Lebih halus
Implementasi	Lebih kompleks
Burst	Lebih terkendali
Memory	Bergantung implementasi
Cocok untuk	API dengan traffic lebih dinamis

3. Token Bucket

Token bucket menggunakan konsep token yang tersedia dalam sebuah bucket. Setiap request membutuhkan token. Jika token tersedia, request dapat diproses. Setelah token digunakan, jumlahnya berkurang.

Token kemudian diisi kembali berdasarkan rate tertentu. Contohnya:

Kapasitas bucket: 100 token
Refill: 10 token/detik

Jika bucket memiliki token yang cukup, client dapat mengirim request. Jika token habis, request dapat ditolak atau menunggu, tergantung implementasi.

Salah satu kelebihan token bucket adalah kemampuannya menangani burst traffic selama masih tersedia token di dalam bucket.

4. Leaky Bucket

Leaky bucket menggunakan konsep bucket yang mengeluarkan request pada kecepatan tertentu. Jika request masuk lebih cepat daripada kecepatan pemrosesan, request dapat masuk ke queue sampai kapasitas tertentu. Ketika queue penuh, request tambahan dapat ditolak.

Pendekatan ini berguna ketika sistem ingin menjaga traffic keluar agar lebih stabil.

Algoritma	Karakteristik Utama	Cocok Untuk
Fixed Window	Counter per interval	Implementasi sederhana
Sliding Window	Menghitung request dalam window bergerak	Kontrol traffic lebih halus
Token Bucket	Memungkinkan burst dengan token	API dengan traffic dinamis
Leaky Bucket	Mengatur output pada rate tertentu	Traffic yang perlu lebih stabil

Rate Limiting Berdasarkan Apa?

Rate limiting dapat diterapkan berdasarkan identitas tertentu. Tidak semua API harus menggunakan satu aturan untuk seluruh traffic. Beberapa pendekatan yang umum digunakan antara lain:

1. IP Address

Limit diterapkan berdasarkan alamat IP client. Contohnya: 100 request/menit/IP

Pendekatan ini sederhana dan dapat berguna untuk API publik. Namun, IP tidak selalu merepresentasikan satu pengguna. Banyak pengguna dapat berbagi satu IP melalui NAT, proxy, VPN, atau jaringan perusahaan.

2. API Key

Limit diterapkan berdasarkan API key.

Contohnya: 1 API key = 1.000 request/jam

Metode ini lebih mudah digunakan untuk layanan yang memberikan API key kepada developer atau aplikasi.

3. User Account

Rate limit dapat diterapkan berdasarkan akun pengguna. Contohnya:

Free Account = 100 request/menit
Business Account = 1.000 request/menit

Dengan cara ini, batas dapat disesuaikan berdasarkan jenis layanan yang digunakan.

4. Endpoint

Setiap endpoint dapat memiliki batas berbeda. Misalnya:

Endpoint	Rate Limit
`GET /products`	1000 request/menit
`GET /profile`	300 request/menit
`POST /login`	10 request/menit
`POST /payment`	30 request/menit

Pendekatan ini berguna karena tidak semua endpoint memiliki tingkat risiko dan kebutuhan resource yang sama.

5. Kombinasi Beberapa Identifier

Dalam sistem yang lebih kompleks, rate limiting dapat menggunakan beberapa parameter sekaligus. Misalnya:

IP address
+
User ID
+
API key
+
Endpoint

Dengan demikian, sistem dapat memiliki perlindungan berlapis.

Apa Itu HTTP 429 Too Many Requests?

Ketika client mengirim request melebihi batas yang ditentukan, server dapat memberikan status:

429 Too Many Requests

HTTP 429 menunjukkan bahwa client mengirim terlalu banyak request dalam periode tertentu. Contoh response:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

Body response dapat berupa:

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests"
}

Header Retry-After dapat digunakan untuk memberikan informasi mengenai kapan client sebaiknya mencoba kembali. Format dan penggunaan header tetap perlu mengikuti desain API yang digunakan.

Apa Itu Retry-After?

Retry-After adalah response header yang dapat digunakan server untuk memberi tahu client kapan request berikutnya sebaiknya dilakukan.

Misalnya: Retry-After: 30

Artinya client disarankan menunggu sekitar 30 detik sebelum mencoba kembali.

Informasi ini sangat berguna untuk aplikasi yang menerapkan retry secara otomatis. Client sebaiknya tidak langsung mengirim request kembali secara terus-menerus setelah menerima HTTP 429 karena tindakan tersebut justru dapat memperpanjang tekanan pada server.

Rate Limiting dan API Gateway

Rate limiting sering diterapkan pada API gateway karena gateway berada di antara client dan service yang berada di belakangnya.

Strukturnya dapat terlihat seperti berikut:

                +----------------+
Client -------->|  API Gateway   |
                +--------+-------+
                         |
                  Rate Limiting
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
      Service A      Service B      Service C

Dengan pendekatan ini, request dapat diperiksa sebelum mencapai service internal. API gateway juga dapat menangani fungsi lain seperti authentication, routing, logging, monitoring, dan traffic management.

Namun, rate limiting pada gateway tidak selalu menggantikan pembatasan di application layer. Endpoint tertentu mungkin membutuhkan aturan tambahan yang memahami konteks bisnis.

Rate Limiting vs Throttling

Rate limiting dan throttling sering digunakan secara bergantian, tetapi konsepnya dapat memiliki perbedaan tergantung implementasi. Rate limiting umumnya berfokus pada menetapkan batas jumlah request dalam periode tertentu.

Sementara itu, throttling lebih luas dan dapat merujuk pada mekanisme untuk mengendalikan atau memperlambat penggunaan resource ketika traffic terlalu tinggi.

Aspek	Rate Limiting	Throttling
Fokus	Membatasi jumlah request	Mengendalikan laju penggunaan
Respons saat limit tercapai	Dapat menolak request	Dapat memperlambat atau menunda
Tujuan	Menetapkan batas penggunaan	Menjaga kestabilan resource
Implementasi	Counter, token, window	Queue, delay, rate control

Dalam praktiknya, sebuah sistem dapat menggunakan keduanya secara bersamaan.

Rate Limiting vs Authentication

Rate limiting tidak sama dengan authentication. Authentication digunakan untuk mengetahui siapa client atau pengguna yang melakukan request.

Sedangkan rate limiting digunakan untuk mengatur seberapa banyak request yang dapat dilakukan. Keduanya dapat bekerja bersama. Contohnya:

Client
   |
   v
Authentication
   |
   v
Rate Limiting
   |
   v
Authorization
   |
   v
API Endpoint

Authentication dapat menentukan identitas pengguna, sedangkan rate limiting dapat menggunakan identitas tersebut untuk menentukan batas request.

Rate Limiting vs Authorization

Authorization menentukan apakah client memiliki izin untuk mengakses resource tertentu. Misalnya:

User A → boleh mengakses /profile
User B → tidak boleh mengakses /admin

Rate limiting memiliki fungsi berbeda:

User A → maksimal 100 request/menit

Karena itu, rate limiting, authentication, dan authorization sebaiknya dipandang sebagai mekanisme yang saling melengkapi.

Manfaat Rate Limiting bagi Keamanan API

Rate limiting dapat memberikan beberapa manfaat dari sisi keamanan.

Mengurangi Brute-Force Request

Endpoint login merupakan salah satu contoh endpoint yang perlu mendapatkan perhatian khusus. Tanpa pembatasan, attacker dapat mencoba banyak kombinasi kredensial dalam waktu singkat.

Rate limiting dapat membatasi jumlah percobaan yang dilakukan dalam periode tertentu. Namun, rate limiting saja tidak cukup untuk mengamankan login. Sistem tetap membutuhkan mekanisme authentication dan security control lain yang sesuai.

Membatasi Automated Abuse

Bot atau script dapat menghasilkan request dalam jumlah besar. Rate limiting dapat membatasi volume tersebut sehingga aktivitas otomatis tidak langsung menghabiskan kapasitas API.

Mengurangi Dampak Traffic Spike

Lonjakan traffic tidak selalu merupakan serangan. Traffic dapat meningkat karena promosi, event, integrasi baru, atau aplikasi client yang tiba-tiba populer.

Rate limiting dapat membantu menjaga agar traffic tetap berada dalam kapasitas yang dapat ditangani sistem.

Cara Menentukan Rate Limit yang Tepat

Tidak ada satu angka rate limit yang cocok untuk semua API. Batas sebaiknya ditentukan berdasarkan karakteristik sistem.

1. Identifikasi Kapasitas Server

Pertama, pahami berapa banyak request yang mampu ditangani sistem secara stabil. Pengukuran dapat dilakukan melalui load testing dan observability.

2. Kelompokkan Endpoint

Tidak semua endpoint membutuhkan limit yang sama. Endpoint yang melakukan query sederhana mungkin dapat menangani request lebih banyak dibandingkan endpoint yang melakukan proses komputasi berat.

3. Perhatikan Jenis Pengguna

API untuk pengguna gratis mungkin memiliki limit berbeda dengan pelanggan berbayar. Contohnya:

Paket	Rate Limit
Free	100 request/menit
Basic	500 request/menit
Business	2.000 request/menit

Angka tersebut hanya contoh. Nilai sebenarnya harus disesuaikan dengan kapasitas sistem dan kebutuhan layanan.

4. Gunakan Data Monitoring

Rate limit sebaiknya tidak ditentukan hanya berdasarkan perkiraan. Perhatikan metrik seperti:

jumlah request;
response latency;
error rate;
CPU usage;
memory usage;
database load;
bandwidth;
jumlah concurrent connection.

Data tersebut dapat membantu menentukan batas yang realistis.

5. Sediakan Buffer

Jika kapasitas maksimum sistem adalah 1.000 request per detik, tidak berarti rate limit harus langsung ditetapkan pada angka tersebut. Sistem perlu mempertimbangkan traffic spike, overhead, dependency eksternal, dan kebutuhan pengguna lainnya.

Bagaimana Client Sebaiknya Menangani Rate Limit?

Rate limiting bukan hanya tanggung jawab server. Client juga perlu dirancang agar dapat merespons pembatasan dengan benar. Ketika menerima HTTP 429, client sebaiknya:

membaca informasi rate limit jika tersedia;
memeriksa Retry-After;
menunggu sebelum melakukan retry;
menggunakan exponential backoff jika diperlukan;
menghindari retry tanpa batas;
mencatat error untuk monitoring.

Contoh sederhana exponential backoff:

Retry 1 → tunggu 1 detik
Retry 2 → tunggu 2 detik
Retry 3 → tunggu 4 detik
Retry 4 → tunggu 8 detik

Dalam implementasi production, biasanya juga digunakan jitter, yaitu penambahan variasi waktu tunggu secara acak agar banyak client tidak melakukan retry secara bersamaan.

Tantangan dalam Implementasi Rate Limiting

Walaupun rate limiting sangat berguna, implementasinya juga memiliki beberapa tantangan.

Shared IP

Banyak pengguna dapat menggunakan alamat IP yang sama. Jika limit hanya berdasarkan IP, pengguna yang sebenarnya berbeda dapat ikut terkena pembatasan.

Distributed System

Pada sistem dengan banyak server, counter rate limit harus dapat dikelola secara konsisten. Misalnya:

Client
  |
  v
Load Balancer
  |
  +---- Server A
  |
  +---- Server B
  |
  +---- Server C

Jika setiap server memiliki counter sendiri, client dapat memperoleh limit berbeda tergantung server yang menerima request.

Karena itu, sistem terdistribusi sering membutuhkan mekanisme shared state atau strategi rate limiting yang sesuai dengan arsitekturnya.

False Positive

Rate limit yang terlalu ketat dapat memblokir pengguna yang sebenarnya sah. Karena itu, konfigurasi perlu mempertimbangkan pola penggunaan normal.

Burst Traffic

Beberapa aplikasi memang membutuhkan burst request dalam waktu singkat. Fixed window yang terlalu sederhana dapat menghasilkan pembatasan yang kurang sesuai. Algoritma seperti token bucket dapat lebih cocok untuk kebutuhan tertentu.

Rate Limiting pada Sistem Terdistribusi

Pada aplikasi modern, API sering dijalankan di banyak instance server. Dalam kondisi tersebut, rate limiter perlu mempertimbangkan konsistensi counter.

Salah satu pendekatan yang umum adalah menggunakan penyimpanan cepat yang dapat diakses oleh beberapa instance aplikasi. Contoh arsitektur:

                 Client
                    |
                    v
              Load Balancer
                    |
          +---------+---------+
          |         |         |
          v         v         v
       API A     API B     API C
          \         |         /
           \        |        /
            +-------v-------+
            | Rate Limiter  |
            | Shared State  |
            +---------------+

Implementasinya dapat menggunakan in-memory store, distributed cache, API gateway, atau komponen khusus lainnya.

Pemilihan teknologi bergantung pada skala traffic, kebutuhan konsistensi, latency, dan arsitektur aplikasi.

Best Practice Menerapkan Rate Limiting

Agar rate limiting dapat bekerja secara efektif, beberapa praktik berikut dapat diterapkan.

1. Tentukan Limit Berdasarkan Kebutuhan

Jangan menggunakan angka yang sama untuk semua endpoint tanpa mempertimbangkan beban masing-masing.

2. Berikan Informasi yang Jelas kepada Client

Jika memungkinkan, API dapat memberikan informasi mengenai limit dan sisa quota melalui response header atau dokumentasi API.

3. Gunakan HTTP 429

Ketika request ditolak karena terlalu banyak request, gunakan status code yang sesuai agar client dapat mengenali kondisi tersebut.

4. Pertimbangkan Retry-After

Jika request dapat dicoba kembali setelah periode tertentu, berikan informasi yang membantu client menentukan waktu retry.

5. Monitor Rate Limit

Pantau jumlah request yang ditolak dan request yang mendekati batas. Jika terlalu banyak pengguna sah terkena limit, konfigurasi mungkin perlu dievaluasi.

6. Pisahkan Limit Berdasarkan Endpoint

Endpoint dengan proses berat dapat diberikan limit lebih rendah dibandingkan endpoint yang ringan.

7. Gunakan Beberapa Lapisan Perlindungan

Rate limiting sebaiknya tidak dianggap sebagai satu-satunya mekanisme keamanan. API tetap membutuhkan authentication, authorization, validasi input, logging, monitoring, dan kontrol keamanan lainnya.

Contoh Strategi Rate Limiting API

Misalnya sebuah platform memiliki beberapa endpoint:

GET /products
POST /orders
POST /login
GET /reports

Strategi rate limiting dapat dibuat berbeda berdasarkan karakteristik endpoint.

Endpoint	Contoh Limit	Alasan
`/products`	1.000 request/menit	Endpoint read dengan traffic tinggi
`/orders`	100 request/menit	Operasi bisnis
`/login`	10 request/menit	Mengurangi automated attempts
`/reports`	20 request/menit	Proses dapat membutuhkan resource besar

Angka tersebut hanyalah ilustrasi. Konfigurasi production harus ditentukan berdasarkan pengujian dan pola penggunaan aktual.

Apakah Semua API Membutuhkan Rate Limiting?

Tidak semua API memiliki kebutuhan yang sama, tetapi rate limiting sangat relevan ketika API:

tersedia untuk banyak client;
dapat diakses melalui internet;
memiliki resource server yang terbatas;
menyediakan API key;
menangani proses yang mahal;
memiliki endpoint authentication;
terintegrasi dengan banyak aplikasi;
berpotensi menerima automated traffic.

Untuk API internal dengan traffic yang sangat terkontrol, penerapannya dapat dibuat lebih sederhana. Namun, sistem tetap perlu mempertimbangkan kemungkinan perubahan arsitektur dan peningkatan jumlah client di masa depan.

Kesimpulan

Rate limiting adalah mekanisme untuk membatasi jumlah request yang dapat dilakukan client terhadap API dalam periode tertentu. Mekanisme ini membantu menjaga penggunaan resource, mengendalikan traffic, mengurangi risiko abuse, dan mempertahankan ketersediaan layanan.

Implementasinya dapat menggunakan berbagai algoritma seperti fixed window, sliding window, token bucket, dan leaky bucket. Rate limit juga dapat diterapkan berdasarkan IP address, API key, user account, endpoint, maupun kombinasi beberapa identifier.

Ketika batas request terlampaui, API umumnya dapat mengembalikan HTTP 429 Too Many Requests dan, jika diperlukan, memberikan informasi seperti Retry-After agar client dapat melakukan retry dengan cara yang lebih terkontrol.

Dalam praktiknya, rate limiting sebaiknya dirancang berdasarkan kapasitas server, karakteristik endpoint, pola penggunaan, serta arsitektur aplikasi. Untuk sistem yang lebih kompleks dan terdistribusi, pengelolaan rate limit juga perlu mempertimbangkan konsistensi antar-instance dan kebutuhan shared state.

Dengan penerapan yang tepat, rate limiting bukan hanya membantu mengendalikan jumlah request, tetapi juga menjadi salah satu bagian penting dalam membangun API yang lebih stabil, terukur, dan siap menangani traffic yang terus berkembang.

Untuk memahami lebih banyak tentang API, cloud, cybersecurity, hosting, dan perkembangan teknologi digital, simak berbagai artikel informatif lainnya di Blog Hosteko.