---
title: "Cara Kirim Jutaan SMS per Hari: Panduan SMS Blast Volume Tinggi"
description: "Kirim jutaan SMS per hari: hitungan perencanaan TPS, SMPP bind dan windowing, antrean, throttling, penanganan DLR, sender ID, jam tenang, dan KPI pemantauan."
canonical: "https://omnichannels.ai/id/blog/high-volume-sms-sending-guide/"
language: "id"
updated: "2026-11-02"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "sms"
primaryQuery: "send millions of sms per day"
keywords: ["kirim jutaan SMS", "SMS blast volume tinggi", "throughput SMS TPS", "SMPP window size", "SMPP bind", "antrean dan rate limiting SMS", "penanganan DLR", "SMS blast jutaan nomor"]
published: "2026-11-02"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 11
answer: "Untuk mengirim jutaan SMS per hari, tentukan kapasitas throughput berdasarkan puncak, bukan rata-rata harian: bagi jumlah segmen yang harus dikirim dengan jumlah detik pada jendela pengiriman, tambahkan cadangan untuk trafik OTP, dan atur window SMPP minimal TPS dikali round-trip time. Gunakan beberapa bind, antrean per operator, dan rate limiter yang mundur saat terkena throttling, proses delivery receipt secara terpisah, dan pisahkan trafik OTP dari promosi."
takeaways: ["Sepuluh juta pesan per hari rata-rata hanya sekitar 116 per detik, tetapi promosi yang dipadatkan dalam jendela empat jam membutuhkan sekitar 694 per detik, dan setiap segmen tambahan melipatgandakannya.", "Spesifikasi SMPP memungkinkan pengirim mengirim banyak permintaan tanpa menunggu respons; jumlah permintaan yang tertunda diserahkan kepada implementasi, jadi window harus disepakati dan disetel. Aturan awal yang baik adalah window minimal TPS dikali round-trip time dalam detik.", "Throttling (ESME_RTHROTTLED, 0x58) dan antrean penuh (ESME_RMSGQFUL, 0x14) adalah sinyal untuk melambat dan mencoba lagi dengan backoff, bukan untuk langsung mengirim ulang.", "Delivery receipt adalah aliran volume tinggi kedua: rencanakan consumer, penyimpanan, dan rekonsiliasinya sama cermatnya dengan submit.", "Kapasitas disepakati per akun dan per rute dengan penyedia Anda; minta angka puncak Anda secara tertulis dan uji sebelum peluncuran."]
faq: 
  - q: "Berapa SMS per detik yang saya butuhkan untuk mengirim satu juta pesan?"
    a: "Bagi jumlah segmen dengan jumlah detik pada jendela pengiriman. Satu juta pesan satu segmen dalam satu jam membutuhkan sekitar 278 per detik, dalam empat jam sekitar 69, dan tersebar sepanjang hari sekitar 12. Pesan multi-segmen dihitung sekali per segmen di sebagian besar platform, jadi pesan dua segmen melipatgandakan laju yang dibutuhkan."
  - q: "Apa itu window size SMPP dan bagaimana mengaturnya?"
    a: "Window adalah jumlah permintaan submit_sm yang boleh tertunda, yaitu sudah dikirim tetapi belum dijawab. Spesifikasi SMPP mengizinkan permintaan asinkron tetapi menyerahkan batasnya kepada implementasi. Aturan praktisnya adalah window minimal target TPS dikali round-trip time dalam detik, lalu naikkan hanya sampai batas yang disepakati penyedia Anda, karena melampauinya menyebabkan throttling."
  - q: "Berapa SMPP bind yang saya butuhkan untuk volume tinggi?"
    a: "Tergantung laju puncak Anda, batas per bind yang disepakati penyedia, dan kebutuhan redundansi. Bagi TPS puncak dengan laju per bind yang disepakati, bulatkan ke atas, dan tambahkan setidaknya satu cadangan agar koneksi yang terputus tidak menghentikan pengiriman. Pisahkan trafik OTP pada bind atau akun tersendiri. Bind disediakan per akun."
  - q: "Apa yang harus dilakukan saat menerima ESME_RTHROTTLED?"
    a: "Melambatlah. Spesifikasi mendefinisikan ESME_RTHROTTLED (0x58) sebagai pengirim yang melampaui batas pesan yang diizinkan. Jeda atau kurangi pengiriman, coba lagi pesan yang ditolak dengan exponential backoff dan jitter, dan jangan pernah mengulang dalam loop rapat, yang memperpanjang throttle. Jika sering terjadi, window atau laju Anda lebih tinggi dari batas yang disepakati."
  - q: "Bagaimana menangani jutaan delivery receipt?"
    a: "Balas setiap deliver_sm dengan deliver_sm_resp segera, taruh receipt di antrean, dan proses secara asinkron ke penyimpanan dengan kunci ID pesan. Buat pemrosesan idempoten, karena receipt bisa berulang. Jalankan consumer receipt terpisah dari jalur submit dan pantau seberapa tertinggal mereka."
  - q: "Bisakah SMS promosi dikirim pada malam hari?"
    a: "Di beberapa pasar tidak. UEA melarang SMS pemasaran pukul 21:00 sampai 07:00 dan Arab Saudi pukul 22:00 sampai 09:00, serta pukul 01:00 sampai 12:00 selama Ramadan. Jadwalkan promosi menurut waktu setempat tiap penerima dan kirim OTP serta notifikasi secara terpisah, karena keduanya bukan promosi."
sources: 
  - title: "SMPP Protocol Specification v3.4, SMPP Developers Forum"
    url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf"
  - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)"
    url: "https://www.3gpp.org/dynareport?code=23040"
  - title: "TDRA spam policy, UAE"
    url: "https://tdra.gov.ae/-/media/About/regulations-and-ruling/EN/cellular-phone-spam-regulatory-policy-English.ashx"
  - title: "CST Regulations for Curbing SPAM Messages and Calls, Saudi Arabia"
    url: "https://www.cst.gov.sa/en/regulations-and-licenses/regulations/Document-522"
---

# Cara Kirim Jutaan SMS per Hari: Panduan SMS Blast Volume Tinggi

Canonical: https://omnichannels.ai/id/blog/high-volume-sms-sending-guide/
Language: id
Publisher: OmniChannels.ai by BroadNet Technologies

Panduan ini ditujukan bagi engineer, pemimpin operasional pesan, dan tim pengadaan yang mengirim, atau akan segera mengirim, satu hingga sepuluh juta SMS per hari. Isinya menunjukkan cara mengubah volume harian menjadi target throughput, mengonfigurasi SMPP bind dan window, membuat antrean dan rate limit, menangani delivery receipt dalam skala besar, serta apa yang perlu disiapkan per negara. Angka dalam contoh adalah angka perencanaan ilustratif, bukan pernyataan tentang kapasitas penyedia mana pun.

## Berapa SMS per detik yang dibutuhkan untuk jutaan per hari?

Anda membutuhkan jumlah segmen dibagi jumlah detik pada jendela waktu yang benar-benar dapat Anda pakai untuk mengirim. Throughput, yang diukur dalam TPS (pesan atau segmen yang disubmit per detik), adalah angka puncak, bukan rata-rata harian. Lihat [throughput (TPS)](/id/glossary/throughput-tps/).

Hitung dulu rata-ratanya, lalu puncak untuk jendela pengiriman Anda yang sebenarnya:

| Pesan per hari | Rata-rata per detik selama 24 jam | Jika dikirim dalam 4 jam | Jika dikirim dalam 2 jam |
|---|---|---|---|
| 1.000.000 | 11,6 | 69,4 | 138,9 |
| 5.000.000 | 57,9 | 347,2 | 694,4 |
| 10.000.000 | 115,7 | 694,4 | 1.388,9 |

Dua pengali mengubah tabel ini:

- **Segmen.** Pesan yang lebih panjang dari satu segmen disubmit sebagai beberapa bagian, dan sebagian besar platform menghitung tiap bagian. 10 juta pesan dengan rata-rata 1,5 segmen berarti 15 juta submit. Kendalikan ini dengan [batas karakter SMS](/id/blog/sms-character-limits-unicode-arabic/) dan [penghitung karakter](/id/tools/sms-character-counter/).
- **Cadangan (headroom).** Tambahkan trafik di luar kampanye, seperti OTP, serta margin untuk retry dan operator yang lambat. Tiga puluh persen adalah kelonggaran perencanaan yang umum, bukan aturan.

## Bagaimana merencanakan throughput dari jam tersibuk, bukan rata-rata?

Rencanakan dari jam atau jendela dengan trafik terbanyak, karena di situlah antrean menumpuk dan throttling muncul. Gunakan rumus ini:

**TPS yang dibutuhkan = (segmen kampanye ÷ detik jendela + TPS puncak OTP dan notifikasi) × (1 + headroom).**

### Contoh kasus: peritel regional

Seorang peritel fiktif mengirim 6 juta pesan promosi dalam sehari ke pelanggan di kawasan Teluk, rata-rata 1,4 segmen per pesan. Ia ingin pengiriman selesai dalam empat jam di dalam jendela siang hari yang diizinkan.

- Segmen: 6.000.000 × 1,4 = 8.400.000.
- Jendela: 4 jam = 14.400 detik, sehingga 8.400.000 ÷ 14.400 = 583 per detik.
- Trafik puncak OTP dan notifikasi selama kampanye: 40 per detik (hasil pengukurannya sendiri).
- Headroom: 30 persen.
- Dibutuhkan: (583 + 40) × 1,3 ≈ 810 per detik.

Angka itulah yang diminta peritel untuk dikonfirmasi penyedianya per rute, secara tertulis, sebelum peluncuran. Ini masukan perencanaan; angka ini tidak menyatakan apa pun tentang apa yang sanggup ditampung platform mana pun.

## Apa itu SMPP bind, dan berapa yang dibutuhkan?

SMPP bind adalah sesi TCP berumur panjang antara sistem Anda dan SMSC penyedia, diautentikasi dengan kredensial dan alamat IP yang diizinkan. SMPP (Short Message Peer-to-Peer) adalah protokol telekomunikasi untuk bertukar SMS, dan dibangun untuk volume berkelanjutan. Lihat [SMPP bind](/id/glossary/smpp-bind/) dan [SMPP vs REST API](/id/blog/sms-api-vs-smpp/).

Ada tiga jenis bind: transmitter (hanya submit), receiver (hanya receipt dan pesan masuk), dan transceiver (keduanya dalam satu sesi). Kebanyakan pengirim memakai bind transceiver.

Cara menentukan jumlah bind:

1. Ambil TPS puncak yang Anda butuhkan.
2. Bagi dengan laju per bind yang disepakati penyedia untuk akun Anda.
3. Bulatkan ke atas dan tambahkan setidaknya satu bind cadangan agar koneksi yang terputus tidak menghentikan pengiriman.
4. Taruh trafik OTP pada bind atau akun tersendiri.

Bind disediakan per akun, jadi tanyakan jumlahnya, laju per bind, dan IP sumber yang diizinkan. Halaman [SMPP gateway](/id/channels/sms/smpp-gateway/) kami dan [dokumen developer SMPP](/developers/smpp/) menjelaskan koneksinya.

## Bagaimana cara kerja windowing SMPP?

Window adalah jumlah permintaan submit_sm yang dapat tertunda sekaligus. SMPP bersifat asinkron: spesifikasi menyatakan pengirim boleh mengirim beberapa permintaan tanpa menunggu respons, dan memakai sequence_number di setiap PDU untuk mencocokkan respons dengan permintaannya. Jumlah maksimum operasi yang tertunda tidak didefinisikan oleh spesifikasi; hal itu diatur oleh implementasi di kedua sisi.

Aturan yang mengikuti dari aritmetika antrean adalah:

**Window ≥ target TPS × round-trip time (detik).**

| Target TPS | Round trip 50 ms | Round trip 150 ms | Round trip 300 ms |
|---|---|---|---|
| 100 | 5 | 15 | 30 |
| 400 | 20 | 60 | 120 |
| 810 | 41 | 122 | 243 |

Window 1 berarti pengirim menunggu setiap respons, yang membatasi throughput pada satu dibagi round trip. Menaikkan window membantu sampai Anda mencapai laju yang diizinkan penyedia; di luar itu Anda hanya menghasilkan throttling. Perlakukan angka ini sebagai sesuatu yang disepakati dengan penyedia dan diuji, bukan dimaksimalkan. Bagi TPS ke beberapa bind bila memakai lebih dari satu: empat bind dengan total 810 TPS masing-masing membawa sekitar 203.

## Bagaimana membuat antrean dan rate limit dalam skala besar?

Taruh antrean yang tahan lama di antara aplikasi dan koneksi SMPP, lalu kuras dengan rate limiter yang dapat diubah saat runtime. Antrean menyerap lonjakan; limiter menjaga Anda pada laju yang disepakati.

- **Token bucket per bind dan per rute.** Isi ulang sesuai TPS yang disepakati; ambil satu token untuk setiap submit_sm, dengan menghitung tiap segmen.
- **Satu antrean per prioritas.** Trafik OTP dan notifikasi lebih dulu, lalu transaksional, lalu promosi.
- **Backoff saat error.** Pada ESME_RTHROTTLED (0x58) atau ESME_RMSGQFUL (0x14), jeda, lalu coba lagi dengan exponential backoff dan jitter. Jangan kirim ulang dalam loop rapat.
- **Sambung ulang dengan backoff** setelah terputus, dan catat sequence number yang masih tertunda agar Anda dapat merekonsiliasi apa yang sudah diterima.
- **Jaga sesi tetap hidup.** Spesifikasi mendefinisikan timer enquire_link untuk memeriksa bahwa pihak seberang masih memiliki sesi aktif dan timer inaktivitas yang setelahnya sesi boleh diputus. Kirim enquire_link saat idle.
- **Submit yang idempoten.** Simpan ID pesan Anda sendiri sebelum submit agar retry tidak mengirim dua kali.

## Bagaimana melakukan routing per operator dalam skala besar?

Buat antrean dan rate limit per operator tujuan selain per bind, karena operator yang lambat tidak boleh menghambat yang lain. Operator dapat membatasi trafik A2P per pengirim atau per rute, sehingga batas efektif untuk suatu negara bisa lebih rendah dari laju akun.

1. Petakan setiap nomor ke operatornya. Number lookup membantu; lihat [HLR lookup](/id/blog/hlr-lookup-number-validation/).
2. Pertahankan antrean dan limiter per operator atau per kelompok rute.
3. Pantau delivery rate dan keterlambatan receipt per operator, dan perlambat yang menurun kinerjanya.
4. Tanyakan kepada penyedia Anda apakah rute langsung dipakai; lihat [direct route vs grey route](/id/blog/grey-route-vs-direct-route-sms/).

## Bagaimana menangani delivery receipt dalam skala besar?

Perlakukan delivery receipt sebagai aliran kedua yang sebesar aliran pertama. Receipt tiba sebagai deliver_sm di bind Anda, dan Anda harus menjawab setiap receipt dengan deliver_sm_resp. Spesifikasi mendefinisikan status akhir dan antara dalam receipt: DELIVRD, EXPIRED, DELETED, UNDELIV, ACCEPTD, UNKNOWN, dan REJECTD. Lihat [delivery receipt](/id/glossary/delivery-receipt/) dan [status pengiriman pesan dijelaskan](/id/blog/message-delivery-status-explained/).

Rancangan yang andal:

1. **Balas dengan cepat.** Jawab deliver_sm_resp segera setelah receipt masuk antrean.
2. **Proses secara asinkron** dengan worker yang mencocokkan receipt ke pesan asli lewat ID pesan.
3. **Buat pemrosesan idempoten.** Receipt bisa berulang, dan pengiriman tidak berurutan mungkin terjadi.
4. **Tangani segmen.** Bergantung pada rute, Anda bisa mendapat receipt per bagian atau per pesan; ujilah.
5. **Tetapkan timeout** untuk pesan yang tidak pernah mendapat status akhir dan tandai sebagai tidak diketahui.
6. **Pisahkan consumer receipt dari jalur submit** agar tumpukan tidak memperlambat pengiriman.

## Apa yang harus didaftarkan per negara sebelum mengirim?

Aturan sender ID berbeda per negara, dan di beberapa pasar pengirim yang belum terdaftar diblokir atau diganti. Contoh: UEA dan Arab Saudi mewajibkan registrasi pada operator, India mewajibkan registrasi DLT untuk header dan setiap template, dan AS memakai 10DLC atau toll-free sebagai ganti pengirim alfanumerik. Lead time berkisar dari beberapa hari kerja hingga sekitar sebulan di pasar yang kami pantau.

Mulailah registrasi lebih dulu, karena berada di jalur kritis peluncuran. Periksa [aturan SMS marketing per negara](/id/blog/sms-marketing-rules-by-country/), [sender ID checker](/id/tools/sender-id-checker/), dan [panduan sender ID untuk UEA dan Arab Saudi](/id/blog/sms-sender-id-registration-uae-saudi/). Kami menyiapkan dan mengajukan registrasi bersama Anda lewat [layanan registrasi](/id/services/registrations/) kami; persetujuan tetap di tangan regulator dan operator.

## Bagaimana menghormati jam tenang pada volume tinggi?

Jadwalkan promosi menurut waktu setempat tiap penerima dan aturan negaranya, dan keluarkan trafik non-promosi dari pembatasan itu. Beberapa pasar mempublikasikan jendela waktu: UEA melarang SMS pemasaran pukul 21:00 sampai 07:00, dan Arab Saudi pukul 22:00 sampai 09:00 serta pukul 01:00 sampai 12:00 selama Ramadan. Lihat [jam tenang (quiet hours)](/id/glossary/quiet-hours/).

- Kelompokkan daftar menurut negara dan zona waktu sebelum masuk antrean.
- Lepaskan tiap kelompok ke antreannya sendiri saat jendelanya terbuka.
- Hentikan antrean promosi di akhir jendela dan pindahkan sisanya ke hari berikutnya.
- Rencanakan urutannya dengan [perencana waktu kirim](/id/tools/send-time-planner/).

Jendela yang sempit menaikkan TPS yang dibutuhkan, jadi masukkan ke dalam rumus perencanaan.

## Mengapa trafik OTP dan promosi harus dipisah?

Pesan OTP dan notifikasi bersifat kritis waktu, sedangkan kampanye promosi bersifat massal; jika berbagi antrean atau bind, kampanye dapat menunda kode login. Gunakan bind atau akun terpisah, sender ID terpisah bila aturan mengharuskan, antrean terpisah dengan prioritas ketat, dan pemantauan terpisah. OTP bukan promosi, sehingga jam tenang tidak berlaku. Lindungi juga rute OTP dari penyalahgunaan: lihat [pencegahan SMS pumping fraud](/id/blog/sms-pumping-fraud-prevention/) dan [panduan OTP](/id/blog/otp-authentication-messages-guide/).

## KPI apa yang perlu dipantau?

Pantau kesehatan submit, usia antrean, hasil receipt, dan keterlambatan receipt, dipisah per negara dan operator. Beri peringatan atas perubahan terhadap baseline Anda sendiri.

| KPI | Rumus | Yang ditunjukkan |
|---|---|---|
| Submit success rate | submit_sm_resp yang diterima ÷ submit_sm terkirim | Kesehatan bind dan akun |
| Throttle rate | Respons ESME_RTHROTTLED ÷ submit_sm terkirim | Laju atau window terlalu tinggi |
| Usia antrean (p95) | Waktu dari masuk antrean hingga submit | Kekurangan kapasitas |
| Delivered rate | DELIVRD ÷ pesan dengan status akhir | Kualitas rute dan konten |
| Porsi gagal dan kedaluwarsa | (UNDELIV + EXPIRED + REJECTD) ÷ status akhir | Validitas nomor, sender ID, penyaringan |
| Keterlambatan receipt (median dan p95) | Waktu receipt − waktu submit | Kelambatan operator |
| Receipt coverage | Status akhir ÷ pesan yang disubmit | Receipt yang hilang |
| Opt-out rate | Balasan STOP ÷ pesan promosi terkirim | Kecocokan audiens dan konten |

Lihat [meningkatkan delivery rate SMS](/id/blog/sms-not-delivered-improve-delivery-rate/) untuk diagnosis.

## Seperti apa checklist peluncuran untuk pengiriman multi-juta?

1. TPS puncak yang dibutuhkan dihitung dari segmen, jendela, dan beban OTP.
2. Laju per bind, jumlah bind, window, dan IP sumber dikonfirmasi tertulis oleh penyedia Anda.
3. Sender ID terdaftar untuk setiap negara, beserta template bila diwajibkan.
4. Uji beban pada sebagian kecil volume, lalu naikkan bertahap; jangan mulai dari maksimum.
5. Antrean, limiter, backoff, dan idempotensi diuji, termasuk pemutusan koneksi paksa.
6. Pipeline receipt diuji pada volume receipt penuh.
7. Penjadwalan jam tenang diverifikasi per negara.
8. Trafik OTP dipisahkan dan dipantau.
9. Dasbor dan peringatan aktif, dengan penanggung jawab siaga.
10. Tombol stop yang menghentikan antrean promosi seketika.

## Bagaimana OmniChannels.ai membantu

BroadNet mengirim SMS lewat konektivitas operator langsung dan mendukung SMPP 3.4 melalui TLS dengan bind yang disediakan per akun, ditambah REST API, pengiriman massal, SMS dua arah, Unicode dan Arab, HLR lookup, serta laporan pengiriman. Kapasitas ditentukan per akun dan per rute: sampaikan tujuan, volume puncak, jendela pengiriman, dan sender ID Anda, lalu kami menyepakati throughput, bind, dan registrasi bersama Anda. Tim kami menyiapkan registrasi sender ID. [Hubungi tim sales](/id/contact/) dengan rencana volume Anda, atau lihat [program wholesale](/id/partners/wholesale/).