How would you organize a Ktor service's routing once it spans dozens of endpoints across features?

## Why this question gets asked Ktor's DSL is pleasant for twenty lines and unmanageable at eight hundred. Because there is no annotation scanning and no per-controller convention, nothing in the framework forces a structure on you — the structure is a choice your team makes, and interviewers ask this to find out whether you have made it deliberately or let a single `routing { }` block grow. ## The core idiom: Route extension functions `routing { }` runs with a `Route` receiver, and every nested `route`/`get`/`post` is just a function on that receiver. So any extension function on `Route` can declare routes: `fun Route.orderRoutes(orders: OrderService) { route("/orders") { get { ... }; post { ... }; get("/{id}") { ... } } }` That file lives with the order feature's code, not in a shared routing package. The application module then reads as a manifest: `routing { route("/api/v1") { orderRoutes(orderService); userRoutes(userService); reportRoutes(reports) } }` One place lists what the service exposes; each feature owns its own paths. New endpoints are added inside the feature's function and require no edit to the central block, which removes the merge-conflict hotspot that a single monolithic routing block always becomes. ## Dependencies as parameters Pass what a route function needs as parameters. The temptation is to have it construct its own service or reach into a global container; both make the wiring invisible at the call site and make substituting a fake in a test awkward. Explicit parameters keep the dependency graph readable from the module function downwards, and they work identically whether you use a DI framework or plain constructor wiring. If a feature needs many collaborators, that is a signal to introduce one façade for the feature rather than to widen the parameter list indefinitely. ## Shared prefixes and grouping Declare a shared prefix once, in the outer block, and never repeat it inside feature functions — a feature function should declare paths relative to wherever it is mounted, which is what makes it reusable and what lets you move a whole feature under a different prefix in one line. The same applies to grouping by cross-cutting boundary: routes that share an authorization boundary are grouped together in the tree, so that boundary is declared once and visibly covers everything nested inside it rather than being restated per handler. ## Keeping handlers thin The second failure mode is not file size but handler depth. A handler that parses input, runs queries, applies rules and formats a response has put business logic inside a DSL that cannot be unit-tested without an HTTP call. Keep the body to three moves: read and validate the request, call a service, respond. Everything the handler needs from the request should be extracted through small shared helpers — one place that converts an id parameter and answers 400 consistently, one place that reads paging — so the error contract does not drift between endpoints written months apart. ## Versioning and evolution Because the prefix is declared once, introducing a second version is a structural edit rather than a rewrite: mount the new feature functions under a new prefix and keep the old branch pointing at the previous implementations for as long as it must live. Whether that is the right versioning strategy is an API-design question, not a Ktor one; what routing gives you is a cheap way to express whichever strategy you chose. ## Testing the seams `testApplication { }` lets you build an application containing only the pieces under test — install the plugins that feature needs, call just `orderRoutes(fakeOrders)`, and exercise it with a client. That is only possible if the route function takes its dependencies as parameters and does not assume the rest of the application exists, so the testability requirement and the wiring rule reinforce each other. Suites built this way stay fast because they never construct the whole service. ## Smells to name in the interview A single routing file over a few hundred lines. Prefixes repeated in path strings, so a rename touches thirty places. Route functions that build their own dependencies. Handlers containing transactions or business rules. Two features declaring overlapping paths because nobody can see the whole tree at once. Naming these concretely, and saying which one you would fix first in a codebase you inherited, is what separates a senior answer from a description of the DSL.