Redirect and rewrite rules in Firebase - Time & Space Complexity
We want to understand how the time it takes to apply redirect and rewrite rules changes as we add more rules.
Specifically, how does the number of rules affect the processing time when a user requests a page?
Analyze the time complexity of applying redirect and rewrite rules in Firebase Hosting.
"hosting": {
"rewrites": [
{ "source": "/old-path/**", "destination": "/new-path/index.html" },
{ "source": "/blog/**", "function": "blogHandler" }
],
"redirects": [
{ "source": "/home", "destination": "/index.html", "type": 301 }
]
}
This configuration applies multiple rewrite and redirect rules to incoming requests.
When a request comes in, Firebase Hosting checks each rule in order.
- Primary operation: Matching the request URL against each redirect and rewrite rule.
- How many times: Once per rule, until a match is found or all rules are checked.
As the number of rules increases, the system checks more rules one by one.
| Input Size (n rules) | Approx. Rule Checks per Request |
|---|---|
| 10 | Up to 10 checks |
| 100 | Up to 100 checks |
| 1000 | Up to 1000 checks |
Pattern observation: The number of checks grows directly with the number of rules.
Time Complexity: O(n)
This means the time to process a request grows linearly with the number of redirect and rewrite rules.
[X] Wrong: "Adding more rules won't affect request speed because they run in parallel."
[OK] Correct: The rules are checked one after another until a match is found, so more rules mean more checks and longer processing time.
Understanding how rule checks scale helps you design efficient configurations and shows you can think about performance in real systems.
"What if Firebase Hosting used a tree structure to organize rules instead of checking them one by one? How would the time complexity change?"