A city’s “common Cisco helper” still ships inside every portal release as a versioned library. The team wants that hop to scale and fail without rebuilding the UI. Which modularity choice matches that goal?
Select an answer to reveal the explanation.
Short Explanation
A shared cookbook still rides in every meal delivery. A separate kitchen can cook, scale, and burn dinner without rebuilding the dining room. Service modularity is a deploy-and-scale boundary—not just a neat folder name.
Full Explanation
When a city's common Cisco helper must scale and fail independently of portal UI releases, library modularity is not enough. A versioned library still ships inside every UI deployable, so helper capacity, crashes, and rollouts remain coupled to the front-end release train. Extracting the hop as its own independently deployable service creates a true runtime boundary: separate scaling, separate failure domain, and UI rebuilds only when the service contract changes.
Keeping the helper as a library and bumping its major version on every UI pixel change fails because version churn does not create independent scale or failure isolation. Copying helper source into each front-end repository fails by creating many divergent forks that look modular in folders but are not independently deployable. Renaming the library package without changing packaging fails because naming is cosmetic; the helper still rides in the UI artifact.
Exam caveat: not every helper must become a service—choose a service when you need independent scale, lifecycle, or blast-radius control; otherwise a well-bounded library may suffice.
Operational check: deploy a helper fix or scale event without rebuilding the portal UI image, and confirm UI pods keep serving while the helper service rolls.