What this prompt does
This prompt turns the model into a senior Java architect that assesses whether a Spring service should migrate from MVC to reactive WebFlux, and forces a clear go/no-go rather than a both-sides shrug. It separates genuine need from hype by checking whether the load profile actually justifies reactive and whether blocking dependencies would negate the rewrite before anyone commits engineering time to it.
The [service_name] variable names the service under review. [load_profile] describes the concurrency and latency characteristics that determine whether reactive's non-blocking model buys anything. [blocking_deps] is the decisive input — JDBC, blocking HTTP clients, or locks each undermine WebFlux, and the assessment explains what each would need (R2DBC, reactive clients, bounded elastic schedulers). [team_experience] weighs the real debugging and familiarity cost of going reactive honestly rather than assuming the team will absorb it for free, since reactive stack traces are genuinely harder to follow.
When to use it
- Someone is pushing to make a service "reactive" and you suspect the real issue is a slow query.
- Deciding whether high concurrency genuinely warrants WebFlux over MVC.
- Auditing blocking dependencies before committing to a rewrite that they might quietly negate.
- Weighing the team's reactive debugging cost against the projected throughput gain.
- Producing a defensible go/no-go with a single biggest-risk callout for stakeholders.
- Deciding what each blocking dependency would have to become for a migration to pay off.
Example output
You get a short findings section, a before/after diff of one migrated endpoint including error handling, and a one-line GO or NO-GO naming the single biggest risk. The findings weigh whether [load_profile] justifies reactive, how each item in [blocking_deps] undermines WebFlux and what it would need, and the honest cost given [team_experience]. It also lists metrics to watch during rollout and a rollback trigger so the migration has a defined abort condition. It's a decision document with one concrete code sample, not a full migration.
Pro tips
- Fill
[blocking_deps]honestly and completely — one JDBC call left in the chain quietly negates the whole rewrite, so this audit usually decides it. - Describe
[load_profile]with real numbers; reactive pays off for high-concurrency I/O-bound fan-out, not for CPU-bound or low-traffic services. - Be candid in
[team_experience]— reactive stack traces and debugging are genuinely harder, and pretending otherwise skews the recommendation. - Use the one-endpoint diff to migrate and measure before committing the whole service; let data, not the prompt, make the final call.
- Name
[service_name]and its real boundaries so the findings stay scoped to the service rather than the whole system. - Keep the rollback trigger and metrics from the output; a migration without a defined abort condition is hard to walk back under pressure.
