# Recently I was working on a communication service built on Twilio Proxy.
- $ Twilio already allocates proxy numbers and routes calls at scale
- $ So the question was never "How do I build a better Twilio?"
- $ The real question was different
## The Core Idea
> How do I make better use of the resources I've already purchased, instead of buying more of them — because infrastructure that scales with traffic also scales cost with traffic.
## The Problem
20,000
Active trips running at any moment
500
Proxy numbers purchased and paid for
15%
Of drivers ever press the Call button
Driver Starts Trip
↓
Create Proxy Session
↓
Allocate Proxy Number
↓
Driver Never CallsThousands of sessions stay alive. Most numbers spend their lifetime reserved instead of useful. The business keeps buying more numbers as traffic grows.
## Idea #1 — Lazy Allocation
Why create a communication session before communication actually begins?
$ trip.start() → session.create()
System: "Every trip gets a number, just in case."
## Idea #2 — Treat Sessions as Temporary
Many users open the call screen and immediately close it. Those sessions become dead weight.
Create Session
↓
No Call Placed
↓
Wait 10 Seconds
↓
Delete Session → capacity returns to the poolShort-lived
Lives for seconds, not for the whole trip
Self-cleaning
Unused sessions expire on their own
## Idea #3 & #4 — Capacity, Not Reservation
Stop asking "which number should I reserve?" and start asking "how much capacity does this number still have?"
Exclusive Reservation
One number is locked to one session
1 Number ↓ 1 Session 500 Numbers → 500 Trips
Ceiling equals the number count
Growth means buying more numbers
## Idea #5 — Admission Control
📞 New session requested
Is capacity available?
→ Check remaining slots
YES
→ Create session
NO
→ Choose another number
## Idea #6 — Dynamic Reallocation
A driver opens the call screen, a session is created, no call happens. That capacity should not stay blocked.
Delete Session
↓
Return Capacity
↓
Allocate Capacity
↓
Next Active UserCapacity keeps flowing toward the users who actually need it.
## Reservation vs Capacity Model
| Feature | Reservation Model | Capacity Model |
|---|---|---|
| Allocated at | Trip start | Call screen open |
| Session lifetime | Whole trip | Seconds |
| Number binding | Exclusive | Shared pool |
| Idle sessions | High | Low |
| Cost curve | Scales with trips | Scales with calls |
## The Patterns I Arrived At
I didn't begin with AI. I began with questions. Only after designing the solution did I ask AI to review it — and that's when the patterns got their names.
Lazy Allocation
Create the resource at the moment of real intent
Resource Pooling
Many sessions share a fixed set of numbers
Capacity-Constrained Allocation
Route by remaining capacity, not by ownership
Admission Control
Decide whether to admit work before doing it
Ephemeral Resources
Unused sessions die quickly and free capacity
Dynamic Reallocation
Capacity flows back to whoever needs it next
## Final Takeaway
Engineering isn't only about making systems faster — sometimes it's about making them more efficient.
If 20,000 trips exist but only 3,000 users ever communicate, the infrastructure shouldn't behave as if all 20,000 need a phone line. Design with:
- Allocation at the point of intent
- Sessions that expire on their own
- Capacity you route to, not numbers you reserve
You get:
> AI didn't invent the solution. It named the patterns ✓