10 Spring Boot Project Ideas for Your Resume (with Scope, Data Model and Working Core Code)

MVP:

• POST /links creates a short code
• GET /{code} redirects
• Reject invalid URLs with validation

Stretch:

• Redis cache in front of the lookup
• Click counts per link and per day
• Expiry date and custom aliases

Core data: links(id, code, target_url, created_at, expires_at) and clicks(link_id, at). Derive code from the numeric id, as below.

The one clever part is the code. Encode the database id in base 62 (digits, lower and upper case). The program ran these values:

static final String ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

static String encode(long id) {
    if (id == 0) return "0";
    StringBuilder sb = new StringBuilder();
    for (long n = id; n > 0; n /= 62) sb.append(ALPHABET.charAt((int) (n % 62)));
    return sb.reverse().toString();
}

static long decode(String code) {
    long n = 0;
    for (char c : code.toCharArray()) n = n * 62 + ALPHABET.indexOf(c);
    return n;
}

-- 1. URL shortener: base62 ids --
0 -> 0 -> 0
61 -> Z -> 61
62 -> 10 -> 62
125 -> 21 -> 125
1000000 -> 4c92 -> 1000000
3521614606207 -> ZZZZZZZ -> 3521614606207
7 characters cover 62^7 = 3521614606208 ids

Seven characters cover 62⁷ = 3,521,614,606,208 ids. Source: ProjectIdeasCores.java, section base62.

Build it with these guides:

• Redis with Spring Boot 4.1: RedisTemplate vs StringRedisTemplate, @RedisHash, Pub/Sub and TTL
• The Spring Cache Abstraction: @Cacheable, @CacheEvict, Key Generators and the Self-Invocation Trap
• springdoc-openapi (document the API)
• Spring Boot Actuator in Production: Every Endpoint, Securing It, and Custom Health Indicators

Resume line template: Built a URL shortener on Spring Boot 4 with Base62 codes, Redis caching and click analytics; handled [N] requests per second in a local load test of [tool].

Trap: Using random codes and checking for collisions on every insert. Encoding the database id has no collisions by construction.

MVP:

• Groups, members and expenses
• Compute each member’s balance
• Return the settle-up transfers

Stretch:

• Unequal and percentage splits
• Currency conversion
• Export as CSV or PDF

Core data: group, member, expense(payer, amount_minor_units), share(expense, member, amount). Store money as integer minor units, never double.

The interesting part is turning balances into the fewest payments. A greedy match of the largest creditor with the largest debtor is simple and good in practice (finding the true minimum is a hard problem in general):

record Transfer(String from, String to, long amount) {}

/** Turns "who paid what" balances into the fewest transfers the greedy method finds. */
static List<Transfer> settle(Map<String, Long> balance) {          // positive = is owed money, negative = owes money
    PriorityQueue<Map.Entry<String, Long>> creditors = new PriorityQueue<>((x, y) -> Long.compare(y.getValue(), x.getValue()));
    PriorityQueue<Map.Entry<String, Long>> debtors = new PriorityQueue<>(Comparator.comparingLong(Map.Entry::getValue));
    for (var e : balance.entrySet()) {
        if (e.getValue() > 0) creditors.add(new AbstractMap.SimpleEntry<>(e));
        else if (e.getValue() < 0) debtors.add(new AbstractMap.SimpleEntry<>(e));
    }
    List<Transfer> out = new ArrayList<>();
    while (!creditors.isEmpty() && !debtors.isEmpty()) {
        var c = creditors.poll(); var d = debtors.poll();
        long pay = Math.min(c.getValue(), -d.getValue());
        out.add(new Transfer(d.getKey(), c.getKey(), pay));
        c.setValue(c.getValue() - pay); d.setValue(d.getValue() + pay);
        if (c.getValue() > 0) creditors.add(c);
        if (d.getValue() < 0) debtors.add(d);
    }
    return out;
}

-- 2. Expense splitter: settle up --
balances {Asha=3000, Ravi=-1000, Meera=-2500, Kabir=500}, sum=0
Meera pays Asha 2500
Ravi pays Kabir 500
Ravi pays Asha 500

In this example four people need three transfers, and no smaller number is possible: no proper subset of the four balances sums to zero, which was checked by brute force. Source: ProjectIdeasCores.java, section settle.

Build it with these guides:

• @Transactional in Spring: Propagation, Isolation, and the Six Ways It Silently Does Nothing
• Spring Data JDBC vs Spring Data JPA in 2026: When Dropping the ORM Is the Right Call
• Global Exception Handling with ProblemDetail (RFC 9457) in Spring Boot 4

Resume line template: Designed a settle-up algorithm that reduces [N] debts to [M] transfers; stored money as integer minor units and covered rounding with tests.

Trap: Using double for amounts. Use long minor units or BigDecimal.

MVP:

• Register and log in, get a JWT
• Boards, columns and cards
• Only owners and members see a board

Stretch:

• Roles per board
• Refresh tokens
• Audit log of changes

Core data: user, board, board_member(role), card.

Build it with these guides:

• Spring Security 7.1 JWT Authentication: The Complete Guide (Spring Boot 4.1)
• Spring Security OAuth2 Resource Server: JWT Validation, JWKS and Key Rotation
• Method Security in Spring Security 7: @PreAuthorize, @PostAuthorize and the Proxy Traps
• CORS, CSRF and SameSite in Spring Boot 4: The Three Settings Everyone Gets Wrong
• Password Hashing in Java: BCrypt vs Argon2 vs PBKDF2 with Spring Security 7

Resume line template: Secured a task-board API with Spring Security 7 JWT authentication and per-board authorization; covered [N] access rules with tests.

Trap: Checking the role but not the owner: any logged-in user can read another user’s board by guessing an id.

MVP:

• Create an order and reserve stock in one transaction
• Publish OrderCreated reliably
• Idempotency key on the payment call

Stretch:

• Saga with compensation
• Dead-letter handling
• Read model for order history

Core data: orders, order_lines, outbox(event, published_at), idempotency(key, response).

Build it with these guides:

• Transactional Outbox with the Spring Modulith Event Publication Registry
• Saga Pattern in Spring Boot: Orchestration vs Choreography with Kafka
• Spring Boot 4.1 and Apache Kafka: Producer, Consumer and Serialisation from Scratch
• CQRS in Spring Boot Without a Framework: Separate Read Models and Projections
• Kafka Error Handling with Spring Kafka 4.1: DLT, Retry Topics and Poison Pills

Resume line template: Implemented the transactional outbox and idempotency keys so order events are never lost or duplicated under retry; verified with a failure-injection test.

Trap: Publishing to the broker inside the database transaction: if one succeeds and the other fails, they disagree. That is what the outbox solves.

MVP:

• Upload with size and type limits
• Stream large downloads
• Per-user quota

Stretch:

• S3-compatible storage
• Pre-signed URLs
• Thumbnails or text extraction

Core data: document(id, owner, name, size, content_type, storage_key). Keep the bytes in storage, only metadata in the database.

Build it with these guides:

• File Upload and Download in Spring Boot 4: Multipart, Streaming and S3 Presigned URLs
• Spring Boot Docker Compose Support: Real Containers for Local Development
• @DataJpaTest in Spring Boot 4.1 with Testcontainers @ServiceConnection

Resume line template: Built a document service that streams multi-gigabyte files without loading them into memory, with quota and type enforcement.

Trap: Reading the whole upload into a byte[]. Stream it.

MVP:

• Limit requests per client key
• Return 429 with Retry-After
• Configurable limits

Stretch:

• Distributed limiter on Redis
• Different limits per route
• Metrics for rejected requests

Core data: A bucket per client key: current tokens and last refill time.

A token bucket allows short bursts but caps the average rate. The version below takes the time as a parameter, so tests need no sleeping:

/** Token bucket: holds up to `capacity` tokens and refills `perSecond` tokens each second. */
static class TokenBucket {
    private final double capacity, perSecond;
    private double tokens;
    private long lastNanos;

    TokenBucket(double capacity, double perSecond, long nowNanos) {
        this.capacity = capacity; this.perSecond = perSecond; this.tokens = capacity; this.lastNanos = nowNanos;
    }

    synchronized boolean tryAcquire(long nowNanos) {
        tokens = Math.min(capacity, tokens + (nowNanos - lastNanos) / 1e9 * perSecond);   // refill for the elapsed time
        lastNanos = nowNanos;
        if (tokens >= 1) { tokens -= 1; return true; }
        return false;
    }
}

-- 6. Rate limiter: token bucket, capacity 3, 1 token per second --
t=0ms -> allowed
t=0ms -> allowed
t=0ms -> allowed
t=0ms -> rejected (429)
t=500ms -> rejected (429)
t=1000ms -> allowed
t=1000ms -> rejected (429)
t=5000ms -> allowed

Capacity 3 lets three requests through at once; the fourth is rejected until a token refills. Half a second later still no token, one second later one. Source: ProjectIdeasCores.java, section bucket.

Build it with these guides:

• The Spring Security Filter Chain Explained: Every Filter, In Order, and How to Debug It
• Redis with Spring Boot 4.1: RedisTemplate vs StringRedisTemplate, @RedisHash, Pub/Sub and TTL
• @Scheduled, ShedLock and Distributed Cron: Scheduling That Survives Three Replicas

Resume line template: Implemented a token-bucket rate limiter as a servlet filter, tested with a fake clock and verified at [N] requests per second against a load generator.

Trap: Using the wall clock in the algorithm, which makes it untestable. Inject the time, as the demo does.

MVP:

• Rooms and messages over STOMP
• Message history endpoint
• Authenticate the socket

Stretch:

• Presence (who is online)
• Typing indicators
• Scale across instances with a broker relay

Core data: room, message(room, sender, body, at).

Build it with these guides:

• Server-Sent Events and WebSocket on Spring Boot 4: SseEmitter, STOMP, and Which to Pick
• RSocket vs gRPC vs WebSocket on Spring Boot 4.1: When Each One Wins
• CORS, CSRF and SameSite in Spring Boot 4: The Three Settings Everyone Gets Wrong

Resume line template: Built a real-time chat on STOMP over WebSocket with authenticated connections and message history, scaled to [N] instances behind a broker relay.

Trap: Keeping sessions in one instance’s memory. The second instance will not know about them.

MVP:

• Consume events and send email or push
• Retry with backoff
• Dead-letter queue for poison messages

Stretch:

• Templates and preferences per user
• De-duplicate events
• Dashboard of failures

Core data: notification(id, user, channel, status, attempts).

Build it with these guides:

• Spring Boot 4.1 and Apache Kafka: Producer, Consumer and Serialisation from Scratch
• Spring Boot and RabbitMQ: Exchanges, Queues, Bindings and a Working Dead-Letter Queue
• Kafka Error Handling with Spring Kafka 4.1: DLT, Retry Topics and Poison Pills
• Testing Asynchronous Code with Awaitility (@Async, Kafka Listeners, Schedulers)

Resume line template: Built an event-driven notification service with retry topics and a dead-letter queue; tested asynchronous behaviour with Awaitility.

Trap: Retrying forever. A message that always fails must end up in a dead-letter destination.

MVP:

• Upload documents, split and embed them
• Ask questions and answer with sources
• Store vectors in pgvector

Stretch:

• Re-index without paying twice
• Guardrails against prompt injection
• Evaluation tests

Core data: document, chunk(document, text, embedding).

Build it with these guides:

• Spring AI 2.0 in 10 Minutes: ChatClient on Spring Boot 4.1
• Choosing a Vector Store for Spring AI: pgvector vs Redis vs Qdrant vs Elasticsearch
• Re-Index a RAG Store Without Paying for Embeddings Twice: VectorStore.upsert() in Spring AI 2.1
• Prompt Injection Defense in Spring AI: Guardrails, Tool Allow-Lists and Output Validation
• Observability for Spring AI: Tokens, Latency and Cost with Micrometer and OpenTelemetry
• Run LLMs Locally with Spring AI and Ollama: No API Key, Testcontainers Included

Resume line template: Built a retrieval-augmented Q&A service with Spring AI and pgvector that cites its sources; added prompt-injection guardrails and an evaluation suite of [N] questions.

Trap: Showing the answer with no source. A reader cannot tell a grounded answer from an invented one.

MVP:

• CRUD for applications and statuses
• Import a CSV in a batch job
• Weekly summary report

Stretch:

• Partitioned import for large files
• Flyway migrations
• Prometheus and Grafana dashboard

Core data: application(company, role, status, applied_at), status_change(application, from, to, at).

Build it with these guides:

• Spring Batch on Boot 4.1: Jobs, Steps, Chunk Processing and Restartability
• Spring Batch Partitioning and Parallel Steps: Scaling a 10-Million-Row Job
• Flyway vs Liquibase for Spring Boot 4: Migrations, Rollbacks and Baselines
• A Practical Guide to Monitoring Spring Boot Microservices: Prometheus, Grafana, and Boot 4.1’s OpenTelemetry Starter

Resume line template: Imported [N] rows per run with a restartable Spring Batch job and versioned schema migrations; added Prometheus metrics for job duration.

Trap: A batch job that is not restartable. If row 80,000 fails, you must not start from row 1 and duplicate the first 79,999.

One of ideas 1, 2 or 3 finished well, with tests and a README, beats a large unfinished one.

Two or three finished ones. Quality and the ability to explain every decision matter more than count.

Only if you can explain why. A well-structured monolith is a good answer; see Modular Monolith vs Microservices in 2026: A Java Decision Framework.

Add what real systems have: validation, error format, pagination, security, tests, migrations and metrics.

You can, but you must understand every line. Interviewers ask “why” about design choices; see AI Coding Agents on a Spring Boot Codebase: A Working Agreement That Keeps the Build Honest.