Hot content, served from inside Punjab.
A localised cache fabric across our Lahore, Islamabad and Faisalabad PoPs for content owners and OTT platforms. Lower upstream transit, faster eyeball delivery, and traffic that stops bouncing through Karachi or Frankfurt before reaching the user three kilometres away.
The cache that lives where the eyeballs do.
The economics of streaming, software distribution and hot static assets in Pakistan are still dominated by submarine-cable transit. Every megabit served from a Singapore or Frankfurt origin shows up twice on the bill: once for the upstream fetch and once for the eyeball deliver. The fix is to keep the bytes inside the country — ideally inside the same metro as the user.
Our edge fabric is a set of cache nodes co-located with our PoPs in Lahore (two sites), Islamabad and Faisalabad. We host customer-managed caches (your image, your config) on our hardware or yours, with anycast-routed front-ends, RPKI-clean announcements, and a measured cache-fill path from origin. We also operate as a delivery partner for hyperscaler-fronted CDNs who want a Punjab footprint without buying real estate.
Workloads we already carry.
OTT video streaming
Local OTT platforms with Punjab-heavy viewership running our cache for the long tail of catalogue content while keeping new releases on origin.
Software and OS updates
Distributed software-update fleets: Linux package mirrors, mobile-OS deltas, browser updates. Hot bytes pinned in cache, cold ones fetched on demand.
Game launchers and patches
Game distribution platforms placing patch traffic on our nodes — typical 80%+ hit ratio during major release windows.
Image and video CDN for marketplaces
E-commerce and classified platforms delivering product imagery from edge instead of origin, cutting page load by 200–400 ms.
Live event ingest distribution
Single-origin ingest fanned out to multiple ABR profiles via our cache, then onward to viewer-side CDNs across Pakistan.
DNS and small-object acceleration
Anycast DNS / small-object front-end on our edge fabric, with health-checked origin fallback.
What we publish on the design doc.
| Metric | Target | Notes |
|---|---|---|
| Edge sites | 4 (LHE × 2, ISB, FSD) | Aligned with our PoPs |
| Per-site capacity | 200 – 800 Gbps | Scales by 100G uplink |
| Compute profile | 1U / 2U cache nodes | Customer-supplied or VCloud |
| Storage tiers | NVMe hot / SATA warm | Sized to working set |
| Anycast | Supported | Customer prefix or shared front-end |
| TLS termination | On-edge (optional) | Customer-provided cert |
| Metric | Target | Notes |
|---|---|---|
| Eyeball RTT (intra-Punjab) | ≤ 20 ms p95 | From cache to typical eyeball |
| Cache hit ratio | Customer-tuned | We report; customer controls policy |
| Origin pull latency | ≤ 200 ms intl. | Via primary upstream |
| Availability | 99.95% per site | Anycast → 99.99% effective |
| Logging | S3-compatible bucket | Per-request, gzip, hourly |
| Purge API | REST + signed URLs | Sub-30s globally |
From design call to production traffic.
- 01
Workload profile
Day 0 – 5. We map your traffic — object size mix, TTL, hot-set size — to a node count and storage tier.
- 02
Hardware + IP
Day 5 – 15. Node racking, anycast prefix coordination, BGP onto our edge.
- 03
Origin + tuning
Day 15 – 22. Origin pull tested, cache rules dialled, log shipping verified.
- 04
Production
Day 22 – 28. DNS cutover, hit-ratio ramp, monthly performance review scheduled.
Pre-sales questions we get.
Are you a CDN or a colocation provider with a cache?
Do you front-end the TLS or do I?
How is billing structured?
Can I see a real hit-ratio report before signing?
Does this work for live video?
What about content compliance?
Bring us a traffic profile, we'll bring you a hit-ratio.
Share a sampled access log or a description of your delivery pattern. We'll come back with a node count, an expected hit ratio and a latency estimate to typical Punjab eyeballs.