good fit
Your team wants visible structure, not framework conventions
Plumego rewards teams that want route ownership, middleware order, and dependency wiring visible in code — not managed behind framework-owned registration.
Use Cases
Scenario-to-module mapping
You have already decided to use Plumego. This page maps seven concrete service scenarios to the exact modules involved, the fit signals to verify, and the best starting point for each. If you are still evaluating fit, start with Why Plumego instead.
Seven scenarios where explicit wiring pays off.
Plumego becomes a stronger fit when the service shape needs to stay readable as the codebase grows, when multiple teams must start from one baseline, or when capability work should stay outside the HTTP kernel.
good fit
You need a stable kernel that stays compatible as capabilities evolve
Stable roots carry long-term compatibility promises. Capability work starts in x/* families so the kernel does not absorb every fast-moving concern.
slow down
You want framework conventions to handle structure automatically
If the team mainly wants routing and dependency setup handled invisibly, Plumego may feel more deliberate than productive.
Scenario walkthroughs.
Each card names the capability modules involved, the fit signals to verify, and the best starting page for that scenario.
internal api
Internal HTTP services where route ownership is visible in review
Use Plumego when a pull request should let reviewers see which routes are registered, which middleware runs in order, and who owns each dependency — without opening framework source code.
- service boundaries matter to reviewers
- bootstrap and handler ownership stay obvious in code
- team already thinks in net/http terms
Modules: core, router, contract, middleware stable roots only
platform service
Shared platform services where multiple teams start from one canonical shape
Plumego is strongest when new services should begin from one readable reference layout rather than each team writing its own bootstrap and routing setup. Structural drift stays low when everyone reads the same canonical starting point.
- new services inherit the same directory and wiring shape
- reviewers accept one small set of patterns across services
- onboarding cost stays low as teams rotate
Modules: reference/standard-service canonical reference
multi-tenant saas
Multi-tenant services with enforced per-tenant routing, quota, and policy
When your service needs JWT-backed tenant identity, per-tenant quota enforcement, and policy evaluation that sits outside the HTTP kernel, reach for x/tenant. Stable roots carry the HTTP baseline; x/tenant carries the tenant layer without mixing the two concerns.
- tenant identity comes from JWT or header, evaluated at the transport layer
- per-tenant quota and policy stay separate from route wiring
- stable roots stay compatible when tenant logic evolves
Modules: x/tenant beta — API stable between minor releases
ai service
AI-capable services with streaming, provider management, and tool routing
Use x/ai when you need multi-provider abstraction, session lifecycle, streaming response handling, and tool-call routing alongside a stable HTTP kernel. Stable roots keep the transport layer compatible; x/ai absorbs the fast-moving AI capability work.
- AI provider abstraction stays separate from HTTP transport
- streaming responses work through standard net/http handlers
- stable roots remain compatible as AI API shapes evolve
Modules: x/ai/provider, x/ai/session, x/ai/streaming, x/ai/tool beta surfaces — stable subpackages within experimental family
api gateway
Reverse proxy and API gateway services with load balancing and edge routing
Use x/gateway when your service needs to proxy requests to upstream backends, apply rewrite rules, or balance load across multiple targets. The stable HTTP kernel handles all transport; x/gateway owns the proxy and edge behavior layer.
- upstream proxy and rewrite rules stay outside the HTTP kernel
- load balancing and backend discovery are explicit in config
- stable middleware handles auth and rate limiting before forwarding
Modules: x/gateway beta — API stable between minor releases
real-time service
Real-time services with WebSocket hubs, rooms, and broadcast
Use x/websocket when your service needs persistent connections, room management, and broadcast alongside standard HTTP routes. WebSocket handling is registered explicitly on routes; the stable kernel does not learn WebSocket semantics.
- WebSocket routes register alongside standard HTTP routes
- hub lifecycle and room management stay separate from HTTP handler logic
- stable transport middleware applies before WebSocket upgrade
Modules: x/websocket beta — API stable between minor releases
messaging service
Services with queues, webhooks, and scheduled tasks integrated into HTTP handlers
Use x/messaging when your service dispatches or consumes jobs, outbound webhooks, pubsub events, or scheduled tasks alongside HTTP routes. The app-facing service layer is beta; subordinate primitives (mq, pubsub, scheduler) remain experimental.
- message dispatch and consumption stay separate from HTTP handler logic
- scheduled tasks and outbound webhooks are declared as service dependencies
- stable transport layer handles request routing independently of messaging
Modules: x/messaging beta — app-facing service layer; primitives are experimental
Not sure which scenario fits?
Read Why Plumego for the longer team-level adoption decision, or inspect Architecture to understand which modules are stable versus experimental before committing.