Context

In a Ruby on Rails monolith serving 10M+ daily requests for an e-commerce marketplace, the router sits on the critical path for every request. A small regression in route matching can increase P99 latency, cause incorrect controller dispatch (user-facing 404s), or accidentally expose admin endpoints if precedence is wrong.

Core Question

You’re asked to explain, at an implementation level, how a Rails-style router could work.

1. Route matching & precedence: How do you decide which route matches a request like GET /users/42/orders/9 when you have static routes (e.g., /users/new), dynamic segments (e.g., /users/:id), and wildcards (e.g., /assets/*path)? What precedence rules prevent /users/new from being captured by /users/:id?
2. Parameter extraction: Once a match is found, how are path parameters (e.g., :id) and wildcard captures extracted efficiently and safely?
3. Performance & data structures: If you have 50k routes (large Rails engines + versioned APIs), what data structures/algorithms would you use to avoid scanning all routes linearly on every request?

Scope Guidance

Discuss internal representation (e.g., tries/DFAs/compiled regex), trade-offs (memory vs speed), complexity, and common pitfalls (route shadowing, ambiguous matches, and pathological patterns). You don’t need to write Ruby, but your explanation should be concrete enough to implement in any language.