If your APAC content delivery strategy still relies on Singapore as the last-mile endpoint for Indonesia, you are overpaying — and your users are already feeling the pinch. For global CDN operators, the case for a Jakarta cache node has shifted from optional optimisation to operational necessity.
Indonesia now ranks as the fourth-largest internet market in the world, and the economics of serving it from offshore have inverted: the transit costs, latency compounding, and peering inefficiencies of a Singapore-only architecture outweigh the capital cost of deploying a Jakarta CDN cache node by a significant margin. This article breaks down the numbers across three dimensions — latency, eyeball topology, and unit economics — for engineering and infrastructure teams evaluating what it actually takes to serve Indonesia at scale.
The ‘Singapore First’ assumption is dead
For years, the standard APAC playbook for CDNs looked like this: deploy a Point of Presence (POP) in Singapore, peer with major regional networks, and let the coverage bleed into Southeast Asia. Singapore made perfect sense — it boasts subsea cable landings, carrier-neutral exchange facilities, clear regulations, and a user base large enough to justify infrastructure costs.
Indonesia has completely broken that calculus.
With approximately 220 million active internet users, Indonesia is now the fourth-largest internet market globally. These users are highly concentrated within a small handful of consumer networks, predominantly access the web via mobile devices, and generate content delivery traffic at a scale that changes the math. Serving them from Singapore — due to latency penalties, transit costs, and peering inefficiencies — is significantly more expensive than running a local cache layer.
This article breaks down why, in language that resonates with engineering leads, procurement teams, and business development directors evaluating Indonesian expansion.
The real latency problem: it’s not just the subsea cables
One-way latency across subsea cables between Singapore and Jakarta hovers around 20ms on a clean path. Round-trip times (RTT) from a Singapore POP to an Indonesian end-user sit at roughly 30–50ms at the 75th percentile — and that is just the international segment. This sounds tolerable until you stack it against the rest of the delivery chain.
Mobile last-mile adds another 30–80ms before a request even hits the international gateway. Since Indonesia’s traffic profile is overwhelmingly mobile, this isn’t an edge case — it is your median user.
Peak-hour congestion on commodity SG-ID transit routes can push p95 round-trip times two to three times higher than the p50 baseline. Packet loss on standard routes routinely spikes past 1% during evening peak hours. The seven most common causes of high server latency — from routing inefficiency to congested transit links — compound on one another in cross-border paths in ways that rarely affect domestic traffic.
For transactional workloads or any content measured by Core Web Vitals — Google web.dev, that tail latency represents a real revenue leak. The full picture of how latency compounds across delivery chains is covered in what impact data latency has and how to mitigate it. Caching locally in Jakarta eliminates the bulk of this issue — but only if those cache nodes peer directly with Indonesian eyeball networks. A Jakarta cache that backfills from Singapore via commodity transit will simply inherit the exact same tail latency you are trying to avoid.
Who rules the Indonesian eyeball space? It’s a short list
Last-mile traffic in Indonesia is heavily concentrated, which is actually excellent news for CDN operators.
The fixed broadband market is dominated by Telkom IndiHome. The mobile segment is split among Telkomsel, Indosat, and XL Axiata. On the alternative fixed side, Biznet, Linknet, and Moratelindo account for the remaining significant volume. According to APJII’s annual survey, the top handful of networks carry the overwhelming share of Indonesian internet traffic. While a long tail of small ISPs exists, they are operationally immaterial for CDN capacity planning.
This concentration means a Jakarta cache node with direct peering to just five or six networks can reach the vast majority of Indonesian end-users in a single hop — completely bypassing international transit. For the principles behind how interconnection and peering work together, those mechanics apply directly to CDN cache architecture.
The recommended architecture is a hybrid approach: private network interconnects for the highest-volume eyeball networks where dedicated port costs are justified by traffic volume, and exchange peering via EPIX to efficiently reach the broader ecosystem. EPIX supports ports from 10G to 400G and connects to major Indonesian ASNs via its route servers, making it the most efficient path to broad market coverage for incoming operators. For a closer look at how EPIX functions as Indonesia’s primary interconnection platform, how internet exchanges make Indonesia’s internet faster covers the exchange architecture in detail.
A quick note for teams accustomed to European or North American markets: in those regions, internet exchanges typically handle the long tail while bilateral agreements cover the primary eyeballs. In Indonesia, that dynamic is flipped. The exchange is often the most efficient path to massive market share, while bilateral peering serves as a supplement rather than the core strategy. PeeringDB — network peering database provides an accurate, up-to-date snapshot of current EPIX ASN coverage.
The economics: outbound transit vs. cache amortization
The financial case for in-country caching becomes obvious the moment you map your traffic profile.
Serving Indonesian users from Singapore means paying egress transit fees on every single bit delivered — forever. While international transit prices continue to drop, at Indonesian traffic scales, that per-bit cost accumulates into a massive line item. And because transit is structurally billed per-bit, there is no amortization benefit as traffic grows; your costs scale linearly with your audience.
In-country caching flips that curve. A cache fill (origin to cache) happens only once per object. Every subsequent request from any user is served domestically over peering links that cost next to nothing per bit. For typical CDN workloads — static assets, video manifests, segment files, and software distribution — cache hit ratios consistently land between 85% and 98%. This means your transit spend drops proportionally to that hit ratio almost the moment the cache goes live.
The capital and operational expenditure of the cache layer itself is remarkably lean. A Jakarta POP designed for large-scale global content workloads can comfortably fit into a modest colocation footprint drawing just over a dozen kilowatts. For most operators with meaningful Indonesian traffic, transit savings will offset the hardware and colocation costs within months.
Pro-Tip: Before finalizing your hardware sizing, pull your access logs to validate hit-ratio assumptions against your actual object inventory. The difference between an 85% and a 95% hit ratio drastically alters your origin fetch bandwidth requirements.
Operational prerequisites: what you must get right before go-live
While a Jakarta cache POP is physically smaller than a full origin deployment, its connectivity requirements are strict. A few nuances often catch operators off guard:
- Cross-connects must be specified during commitment, not negotiated later. A POP launched with EPIX exchange peering that lacks direct cross-connects to the dominant fixed-line operators will still route its largest traffic flows suboptimally. Confirm cross-connect availability and pricing before signing data center contracts.
- BGP policy tuning takes longer than expected in this market. Default policy configurations optimized for Singapore POPs frequently cause routing anomalies related to Multi-Exit Discriminators (MED) with Indonesian peers. Route reflector setups that work flawlessly in internationally well-connected environments can lead to suboptimal path selection from a Jakarta cache. Tools that peering coordinators rely on — including route-server looking glasses and IRR validators — are essential during this tuning phase. Allocate dedicated engineering time for policy tuning during the first few weeks of operation.
- Remote hands SLA quality is critical for distant POPs. For operators whose engineering teams are based in Singapore or further afield, the on-site data center team is the first line of defense for any hardware failures requiring physical intervention. A 4-hour resolution SLA with after-hours coverage is the bare minimum; anything looser can turn a minor hardware swap into days of degraded service.
The bigger picture: interconnection as an infrastructure strategy
The decision to deploy a Jakarta cache node is part of a larger truth: interconnection quality determines whether infrastructure investments translate into real-world performance — or simply add underperforming capacity because it cannot properly connect to local networks.
Indonesia exemplifies a pattern seen across fast-growing Asian markets: capacity investment has outpaced interconnection development. This bottleneck manifests as “hairpin” routing (where traffic between two networks in the same city hops through an international hub first), inflated transit costs for what should be domestic traffic, and performance gaps that disproportionately hurt real-time applications.
Markets that address this systematically — through carrier-neutral facilities, dense cross-connect ecosystems, and robust exchange platforms — unlock massive advantages: lower delivery costs, superior Core Web Vitals, faster time-to-market for new services, and seamless alignment with data localization regulations increasingly shaping Southeast Asia’s digital landscape. Digital Edge’s Jakarta facilities deliver on this directly: ultra-low latency downtown infrastructure for financial and digital platforms, carrier-neutral interconnection, and the ecosystem depth to support future hyperscale and AI expansion.
Conclusion
If you have significant traffic bound for Indonesian users and your architecture still leans solely on a Singapore POP, three realities apply.
You are paying significantly more for transit than you would with local caching. Your tail latency metrics are missing standards you would consider unacceptable in European or North American markets. And the solution — a Jakarta cache node paired with proper domestic peering — features a payback period measured in months, not years.
The Singapore-as-the-sole-APAC-hub model has run its course. For Indonesia specifically, it is operationally obsolete. The question now is when you execute your local migration, not if.
Digital Edge interconnection services at our carrier-neutral Jakarta facilities bring together EPIX exchange peering, private interconnects to Indonesian eyeball networks, and colocation built for connectivity-dense CDN workloads — reach out to our team to discuss cache deployment and peering options for the Indonesian market.
