Meeting Rooms II (Min Rooms) Explained: Rooms for [[0,30],[5,10],[15,20]]

Imagine you are managing event spaces and you receive three bookings: Given meetings $\text{[[0,30], [5,10], [15,20]]}$. The first meeting spans the entire hour and a half from time 0 to 30. Shortly after it begins, a second short meeting kicks off from time 5 to 10, and a third runs from time 15 to 20.

If you blindly assign every incoming booking to a brand-new physical room, you will quickly run out of space. But look closely at the overlap: when the second meeting starts at 5, the first room is still actively occupied by the long meeting. You cannot share that room yet. You need a second room.

However, by the time the third meeting arrives at 15, the second meeting has already finished at 10. Without a smart allocation strategy, it is entirely too easy to waste capacity by keeping doors locked or buying unnecessary real estate. We need a systematic way to track peak concurrency without manually drawing timelines.

When we look at our meetings [[0,30],[5,10],[15,20]], our goal is to find the peak number of overlapping intervals occurring at any single instant. Imagine dragging a vertical timeline sweep-line from time $t=0$ to $t=30$. Every time a meeting starts, our room demand increases by one; every time a meeting ends, a room becomes available for reuse.

In our working example, the first meeting starts at $t=0$ and claims a room until $t=30$. When the second meeting begins at $t=5$, it cannot use that same room because the first meeting is still active. This forces us to allocate a second room. However, when that second meeting ends at $t=10$, its room is immediately freed. When the third meeting starts at $t=15$, it steps into the newly vacated room instead of demanding a third one.

To formalize this model, we separate our interval list into two independent timelines: a list of start times and a list of end times. Sorting these timelines allows us to track resource demand chronologically without getting bogged down in individual meeting pairings. The peak concurrency across these sorted events dictates our minimum room requirement.

Now we apply our timeline model to the concrete meetings [[0,30], [5,10], [15,20]]. Instead of checking every minute on a clock, we isolate the critical event timestamps: when meetings begin and when they end.

First, we separate and sort the start times and end times independently:
- Starts: $[0,5,15]$
- Ends: $[10,20,30]$

We use two pointers, $i$ for starts and $j$ for ends, along with a running room counter and a peak room counter.

Given:
- starts = $[0,5,15]$
- ends = $[10,20,30]$
- $i=0,j=0,\text{rooms}=0,\text{maxRooms}=0$

Steps:
1. $i=0$ ($start=0$): Compare $\text{starts}[0]$ (0) with $\text{ends}[0]$ (10). Since $0<10$, a new meeting starts before the earliest one finishes. We increment $\text{rooms}$ to 1 and advance $i$ to 1. $\text{maxRooms}$ becomes $max(0,1)=1$.
2. $i=1$ ($start=5$): Compare $\text{starts}[1]$ (5) with $\text{ends}[0]$ (10). Since $5<10$, another meeting starts before any room empties. We increment $\text{rooms}$ to 2 and advance $i$ to 2. $\text{maxRooms}$ becomes $max(1,2)=2$.
3. $i=2$ ($start=15$): Compare $\text{starts}[2]$ (15) with $\text{ends}[0]$ (10). Since $15\ge 10$, a meeting has finished! We decrement $\text{rooms}$ to 1 and advance $j$ to 1. $\text{maxRooms}$ stays 2.

Result:
After processing all starts, the maximum rooms active concurrently is 2, matching our expected result for [[0,30], [5,10], [15,20]].

Now that you have seen how the timeline scan tracks concurrent intervals using sorted start and end arrays, it is time to test your mental model. Instead of the original meetings [[0,30], [5,10], [15,20]] which required 2 rooms, let us modify the schedule slightly. Consider the meetings schedule [[0,10], [5,15], [10,20]]. Walk through the start pointer and end pointer technique manually. Keep track of how many rooms are occupied at each time event and determine the peak concurrency.

def minMeetingRooms(intervals):
    # Try tracing meetings = [[0,10], [5,15], [10,20]]
    pass

The dual-array pointer technique we used for the meetings $\left[[0,30],[5,10],[15,20]\right]$ is not just for physical conference rooms. Whenever you need to track peak concurrent usage across overlapping intervals—whether network connections, CPU thread allocations, or cloud virtual machine instances—the fundamental constraint remains identical: resource demand peaks whenever a new start event occurs before the earliest active end event resolves.

To test this transfer of knowledge, consider a cloud logging service that receives incoming batch jobs instead of meetings. Each job has an arrival timestamp and a completion timestamp, represented as time intervals. If you process incoming jobs with request windows $\left[[1,4],[2,5],[7,9]\right]$, the exact same sorting logic applies. The start times are $[1,2,7]$ and the end times are $[4,5,9]$. By walking through these sorted events just like we did with our conference rooms, you can instantly determine the maximum concurrent worker threads required without simulating every single second of execution.

Whenever you encounter a scheduling bottleneck where intervals overlap, look past the domain-specific nouns. Strip away whether they are people in a room, packets on a wire, or tasks on a queue, and reduce them to their boundary events. Sorting starts independently from ends transforms an $O(n^2)$ naive search into a clean $O(n\log n)$ sweep-line traversal.