What does a Spring Boot developer build?
A Spring Boot developer builds Java (or Kotlin) server applications on the Spring ecosystem: REST APIs, integration services, scheduled batch jobs, event consumers and the back ends behind web and mobile apps. Spring Boot's role is to remove setup work, with auto-configuration, embedded servers and starter dependencies, so the developer spends time on business rules rather than wiring.
Organisations choose Spring Boot for work where correctness and longevity matter more than speed of the first prototype. Banks, insurers, logistics operators, hospitals and manufacturers run large Java estates, and their partners often expect integrations in the same stack. Spring Security, Spring Data and Spring Cloud cover most of what such systems need, and the talent pool in India is deep.
The job is wider than controllers. A Spring Boot developer you can rely on designs the API contract, models the database, configures security, handles transactions, writes tests at several levels, packages the service in a container and sets up monitoring so problems appear on a dashboard before they appear in a customer complaint.
- REST endpoints with validation, pagination and consistent error responses
- Authentication and authorisation with Spring Security
- Relational data with Spring Data JPA and Hibernate
- Messaging with Kafka or RabbitMQ for events and background work
- Containers, probes and metrics for production operation
Spring Boot 3 or Spring Boot 4: which version should your project use?
Start new projects on the current Spring Boot 4 line unless a library you depend on is not ready; keep existing Spring Boot 3 applications on a supported 3.x release and plan the move. At the time of writing, spring.io lists Spring Boot 4.1.1 as the current release.
The Spring Boot 4.1.1 system requirements page states a minimum of Java 17 (supported up to Java 26), Spring Framework 7, and Servlet 6.1 containers such as Tomcat 11 and Jetty 12.1. Spring Boot 3 already required Java 17 and moved from javax to jakarta package names, which is why upgrades from Spring Boot 2 are the heavier jump.
For a new build we prefer a long-term-support Java release (21 or 25) so the runtime stays patched for years. For a Spring Boot 2 application, we plan a two-step route: first to the latest 3.x with the jakarta namespace change and the Spring Security configuration rewrite, then on to 4.x once tests are green. Support windows change, so we check spring.io's support calendar for your exact versions in the quote rather than quoting dates from memory.
Stuck on an older Java version as well? Our Java developer page covers Java 8-to-21 upgrades and legacy J2EE systems.
Designing REST APIs in Spring Boot that partners will not hate
A good Spring Boot REST API is predictable: resource-oriented URLs, validated request bodies, one error format everywhere, pagination on every list, and published OpenAPI documentation. Partners judge your API by its edge cases, not its happy path.
We define request and response DTOs separately from JPA entities, so database changes do not leak into the public contract. Bean Validation annotations reject bad input with a 400 response naming the field. A global exception handler turns every failure into the same JSON shape (Spring supports the standard Problem Details format), so client developers write one error handler instead of twenty.
Versioning is decided on day one, whether in the path or a header, and older versions are retired on a written schedule. OpenAPI documentation generated with springdoc gives mobile and partner teams a browsable reference and a way to generate typed clients.
- DTOs for the contract; entities stay internal
- Validation at the controller boundary with clear field errors
- Idempotency keys on payment and order creation endpoints
- Cursor or page-based pagination with stable sorting
- Rate limits and request size limits for public endpoints
How should a Spring Boot developer set up Spring Security with JWT or OAuth2?
For most APIs, configure the service as an OAuth2 resource server that validates signed JWTs from a trusted identity provider, then protect endpoints by scope or role. Avoid inventing your own token scheme.
Spring Security's reference documentation shows the minimal set-up: add the resource-server dependencies and set spring.security.oauth2.resourceserver.jwt.issuer-uri to your identity provider's issuer. Spring then discovers the provider's public keys, validates each token's signature and issuer, and by default turns the token's scopes into authorities prefixed with SCOPE_. A converter can map a custom roles claim instead.
The identity provider can be Keycloak, a cloud service such as Amazon Cognito, or another OAuth2/OIDC provider your organisation already runs. For smaller products that do not need single sign-on, we can issue signed JWTs from the application itself, with short expiry, refresh tokens and a revocation list.
- SecurityFilterChain beans, not the removed WebSecurityConfigurerAdapter
- Deny by default; public endpoints listed explicitly
- Method-level checks for sensitive operations
- Data scoping so one tenant or branch never reads another's records
- Tests for every role on every sensitive endpoint
Security reviews are where a second developer earns their keep. On our team, no change to security configuration merges without another developer reading it.
Spring Data JPA and Hibernate: fast to write, easy to misuse
Spring Data JPA lets a developer declare a repository interface and get common queries for free, which makes CRUD work quick. The same convenience hides performance traps that only appear with real data volumes.
The classic one is the N+1 query: a list screen loads fifty orders, then quietly runs fifty more queries to fetch each customer. Others include lazy-loading exceptions papered over by leaving open-in-view on, loading whole entity graphs for a simple summary, and missing indexes on the columns used for filtering.
A Spring Boot developer worth hiring checks SQL logs during development, uses fetch joins or entity graphs deliberately, writes projections for read-heavy screens, and keeps transactions short. Schema changes go through Flyway or Liquibase migrations committed with the code, so every environment matches.
PostgreSQL or MySQL?
Both are fine with Spring Data JPA. We lean to PostgreSQL for new builds for its JSONB support, strong constraints and extensions; MySQL is a sensible choice when your team or host already standardises on it.
When to step outside JPA
Heavy reports and bulk updates are often clearer in plain SQL through JdbcClient or jOOQ. Mixing approaches is fine when each has a clear job.
Spring Boot microservices with Spring Cloud: what each piece does
Spring Cloud supplies the plumbing that distributed Spring Boot services need: a gateway for routing, central configuration, service discovery, declarative service-to-service calls, circuit breakers and event streaming. You pick only the pieces your system requires.
The Spring Cloud project page lists these building blocks, including Spring Cloud Gateway, Spring Cloud Config, Netflix Eureka discovery, OpenFeign clients, Circuit Breaker, Spring Cloud Stream for Kafka or RabbitMQ messaging, and Spring Cloud Kubernetes. It also shows the current 2025.1 release train as compatible with Spring Boot 4.0 and 4.1, a pairing a developer must check before adding dependencies.
On Kubernetes, some of these become optional: the platform already provides service discovery and configuration through services, ConfigMaps and Secrets. Running Eureka inside Kubernetes duplicates what the cluster does. The gateway and circuit breakers usually remain useful wherever you run.
If you are also weighing a Kubernetes platform itself, our Kubernetes consulting page explains when a cluster is worth running.
Do you really need microservices, or a well-structured Spring Boot monolith?
Most projects we scope are better as one Spring Boot application with clear internal modules. Split into microservices when a part needs to scale, deploy or fail independently, or when separate teams own separate parts.
Microservices trade code complexity for operational complexity. Each service brings its own pipeline, database, monitoring, version compatibility and network failure modes. A team of three to six developers running twelve services spends much of its time keeping the platform alive rather than building features.
Our approach: organise the monolith by business capability (orders, billing, catalogue, notifications) with package boundaries enforced, one database schema per module where practical, and events between modules. If orders later need to scale separately, that module already has the shape of a service and can be extracted with Spring Cloud pieces around it.
This is not a sales position against microservices. For a platform ingesting high-volume telemetry alongside a low-traffic admin portal, we would separate the ingestion service from day one, because the load profiles differ sharply.
Deploying Spring Boot on Docker and Kubernetes
Package each Spring Boot service as a container image, run it with externalised configuration and secrets, and wire Kubernetes liveness and readiness probes to Spring Boot Actuator. For one or two services, a container platform or a well-run VM can be simpler than a full cluster.
Spring Boot's Actuator documentation explains that when the app runs on Kubernetes, it exposes liveness and readiness health groups at /actuator/health/liveness and /actuator/health/readiness, and that by default only the health endpoint is exposed over HTTP. That default is sensible: metrics and environment endpoints should be exposed deliberately and protected.
The JVM needs care in containers: memory limits set so the heap fits, CPU requests that reflect startup cost, and graceful shutdown so in-flight requests finish during rolling updates. Images can be built with Spring Boot's buildpack support or a layered Dockerfile. Pipelines build, test and scan images before deploying. See CI/CD pipeline setup for the build side.
- Probes mapped to Actuator health groups
- Config through environment variables and mounted secrets, never baked into images
- Resource requests and limits tuned from load tests
- Structured logs, metrics and traces to your chosen monitoring tool
- Rollback in one command, documented and rehearsed
Kafka and RabbitMQ with Spring Boot: when events beat API calls
Use messaging when one action must trigger work elsewhere without making the user wait, or when several systems need to react to the same event. Order placed, payment confirmed, shipment dispatched: these are events, not function calls.
Spring Boot integrates with both Kafka and RabbitMQ, directly or through Spring Cloud Stream. RabbitMQ suits task queues and routing to specific consumers; Kafka suits high-volume event streams that several consumers read and replay. For many Indian SMEs a database-backed outbox plus RabbitMQ is plenty, and Kafka is only justified at real volume.
Reliability matters more than the broker choice. Consumers must be idempotent because messages can arrive twice, failed messages need a dead-letter destination someone watches, and the transactional outbox pattern prevents the classic bug where the database commits but the event never goes out.
How is a Spring Boot application tested properly?
With several layers: fast unit tests for business logic, slice tests for controllers and repositories, integration tests against real databases in containers, and a few end-to-end checks of the most important flows.
JUnit 5 is the default test framework. Slice annotations such as @WebMvcTest and @DataJpaTest start only part of the application, so they run quickly. Testcontainers starts a real PostgreSQL, Kafka or RabbitMQ in Docker for integration tests, which catches problems an in-memory database would hide, such as SQL dialect differences.
We weight tests toward risk: security rules for every role, money and stock calculations, migrations, and message handling. All of it runs in CI on every pull request, and a failed test blocks the merge.
A good question for any Spring Boot developer you are considering: “Show me a test that proves a normal user cannot call an admin endpoint.” The answer tells you a lot.
Spring Boot services are fast once warm; the usual complaints are memory use and startup time, which matter most for autoscaling and small containers. Both can be improved without rewriting the application.
On Java 21 and later, Spring Boot can run request handling on virtual threads through a single configuration property, which helps services that spend most of their time waiting on databases and other APIs. For startup-sensitive workloads, GraalVM native images are an option; the Spring Boot 4.1.1 requirements page lists GraalVM Community 25 support. Native builds take longer and some libraries need extra configuration, so we test before committing.
Before either, we profile. The slowest part of a Spring Boot API is almost always a database query, an external call without a timeout, or serialising far more data than the client needs. Fixing those costs less than bigger servers.
How much does it cost to hire a Spring Boot developer in India?
With BtechWaleTech, a Spring Boot REST API or web application starts from ₹60,000 (US$900) and usually takes 6–12 weeks. AI features added to a Spring Boot platform, such as document reading or an assistant, start from ₹40,000. Maintenance after the free two months starts from ₹8,000/mo.
Rates for Spring Boot developers in India vary widely between freelancers, product engineers and IT services vendors, and hourly figures rarely tell you what a project will cost. A project estimate should be built from the items below, each visible in the quote:
- Number of domain modules and endpoints
- Security model: local JWT, OAuth2 with an external provider, or both
- One deployable service or several, and whether Kubernetes is needed
- Messaging with Kafka or RabbitMQ
- Integrations with payment, ERP, CRM, logistics or government APIs
- Data migration from an existing system
- Test depth, documentation and monitoring expectations
For a broader view of software budgets, read custom software development cost in India.
How to vet a Spring Boot developer before hiring
Give a short paid exercise on a small Spring Boot codebase: add a secured endpoint, fix a planted N+1 query, and write an integration test with Testcontainers. Review the pull request and discuss it on a call.
Resumes list the same annotations; exercises reveal judgement. You want to see whether they notice the N+1 problem without being told, how they configure the security rule, whether their test would actually fail if the rule were wrong, and how clearly they explain trade-offs.
Questions that separate levels
How does the SecurityFilterChain decide which rule applies? What does @Transactional do on a private method? When would you turn off open-in-view? How do you make a Kafka consumer idempotent? What do readiness probes protect you from during a deploy?
Green flags
They ask about data volume, roles and integrations before designing; they mention migrations, timeouts, idempotency and observability without prompting; they suggest fewer services, not more.
Red flags
Entities returned directly from controllers, security rules copied from an old tutorial, no tests, credentials in application.properties committed to Git, and a proposal for a dozen microservices on a small project.
Spring Boot, NestJS or FastAPI: choosing a backend stack
Choose Spring Boot when your organisation or partners standardise on Java, when you need mature transaction handling and security integrations, or when the system will be maintained by Java teams for many years. Choose NestJS for TypeScript-first teams sharing code with a React front end. Choose FastAPI when the core of the product is Python ML or LLM work.
All three can produce excellent APIs; the deciding factors are people and ecosystem. If your future in-house hires will be Java developers, a Spring Boot codebase is easier to hand over. If your data science team writes Python, a FastAPI service beside a Spring Boot core is a common and sensible pairing.
Compare the details on our pages to hire a NestJS developer and to hire a FastAPI developer, or on Go developers for lean, high-throughput services.
Code ownership, handover and running the service after launch
Everything belongs to you: the Git repository, container registry, cloud account, databases, identity provider configuration and third-party integrations. We work with access you grant and can remove at any time.
Handover includes the source, OpenAPI specification, database migrations, a service map, a runbook covering deployment, rollback, backups, certificate renewal and common alerts, plus a recorded walkthrough for your team or a future hire. Java teams can pick up a well-structured Spring Boot codebase quickly, which is one reason organisations choose the stack.
Two months of free maintenance follow go-live. After that, maintenance starts from ₹8,000/mo (US$120/mo) and covers dependency and CVE updates, Spring Boot minor upgrades, monitoring and small changes. Major version upgrades are quoted separately.
Worked example: a hypothetical service platform for a Coimbatore pump maker
Say a pump manufacturer in Coimbatore wants a platform where dealers register sales, customers log warranty claims from a mobile app, and field technicians receive and close service jobs. This is an illustrative scoping, not a past client.
We would propose one Spring Boot application with modules for Dealers, Products and Serial Numbers, Warranty, Service Jobs, Technicians and Notifications, on PostgreSQL with Flyway migrations. Spring Security would act as a resource server for tokens issued by Keycloak, with roles for manufacturer staff, dealers, technicians and customers, and dealer data scoped per dealership. RabbitMQ would carry events such as “claim approved” to a notifications consumer that sends WhatsApp and SMS updates.
Deployment would be two containers (API and notification worker) on a managed container service rather than Kubernetes, because two services do not justify a cluster. The technician and customer app could be a Flutter app from ₹40,000. The first milestone, covering dealers, serials and warranty claims, would take about eight weeks; service jobs follow in a second milestone. If job volume grows sharply later, the Service Jobs module is already shaped to become its own service.
Checklist before you hire a Spring Boot developer
Ask for each of these in writing, whoever you hire. Missing answers are cheaper to discover now than during go-live.
- Service or module map, with a reason for every separate service
- Spring Boot and Java versions chosen, with support windows checked
- Security model: identity provider, token type, roles and scopes
- Database, migrations tool and indexing plan
- Messaging choice and how duplicates and failures are handled
- Test layers, including Testcontainers integration tests in CI
- Container build, probes, config and secrets approach
- Monitoring: logs, metrics, alerts and who receives them
- Code, cloud and identity-provider accounts in your name
- Itemised quote per milestone; nothing billed before written approval