How do you decide whether a new feature should be its own microservice or part of an existing Spring Boot service?

This is a genuinely important architectural judgment call, and the "default to microservices" instinct is often wrong — splitting a service is a real, non-refundable cost (added network calls, independent deployment/monitoring overhead, new distributed-systems failure modes) that should be justified by a concrete benefit, not applied reflexively as a best practice.

Reasons that genuinely justify a new, separate service:

• A meaningfully different scaling profile — e.g., an image-processing feature that's CPU-intensive and bursty deserves to scale independently from a mostly I/O-bound, steady-traffic order API; bundling them means scaling one forces over-provisioning the other.
• A different release cadence or ownership boundary — a separate team that needs to deploy on its own schedule, without coordinating releases with an unrelated team's service, benefits genuinely from an independent deployable unit.
• A different technology requirement — a feature that's a much better fit for a different language/runtime (e.g., a machine-learning inference service in Python) obviously can't just be "added to" an existing Spring Boot service.
• A genuine domain boundary (Domain-Driven Design's "bounded context") — a feature that represents a conceptually distinct business capability, with its own data model and vocabulary, that would otherwise blur into a very different existing service's own domain model.

Reasons that usually don't justify splitting it out:

• "It felt cleaner as its own thing" — cleanliness is achievable with good package/module structure inside an existing service, without paying the network/deployment tax of a separate service.
• "Microservices are the modern best practice" — applied without any of the concrete pressures above, this mainly adds complexity (service discovery, inter-service auth, distributed tracing, eventual consistency) without a corresponding, specific benefit.
• A small team maintaining the resulting sprawl of many tiny services often ends up worse off than a well-organized modular monolith, purely from the added operational overhead of many independently deployed pieces.

A practical approach in an interview answer: start by keeping a new feature inside the existing, appropriately-bounded service by default; only split it out once one of the concrete pressures above (scaling, ownership, technology, or a real domain boundary) actually materializes — and be ready to justify which specific pressure is driving the decision, rather than treating "more microservices" as an unconditional good.