AI coding agents are only as useful as the context you give them. Feed too little and they generate generic code that ignores your architecture. Feed too much — a 500-line style guide, every ADR, every naming convention — and you burn through the context window before the real work begins, leaving the model slower and less accurate.

The real problem is not what to tell the agent. It is when. Your deployment checklist is irrelevant when you are writing a unit test. Your frontend component rules should not be loaded when you are tuning a SQL query. Static system prompts cannot make that distinction.

Agent Skills solve this with on-demand context loading: the agent reads only a short description for each skill at startup, then pulls the full instructions only when your task actually calls for them.

What are Agent Skills?

Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows. The agentskills.io specification is standardizing this so skills remain portable across different AI products.

At its core, a skill is a folder containing a SKILL.md file. This file has YAML frontmatter (name and description) followed by the instructions that tell the agent how to perform a specific task. Skills can also bundle scripts, reference materials, and templates.

my-skill/
├── SKILL.md            # Required: metadata + instructions
├── scripts/            # Optional: executable code
├── references/         # Optional: documentation
├── assets/             # Optional: templates, resources
└── ...

Where skills live

The directory depends on which AI tool you’re using:

Why not AGENTS.md or rules?

AGENTS.md/Claude.md/Cursor rules all solve the same problem: telling the agent how to behave. The difference is when the context loads.

AGENTS.md is read at the start of every session. Every token in that file counts against your context window for every task, whether you’re writing docs, debugging a race condition, or refactoring a database layer.

Skills load on demand. The agent reads only the metadata (name and description) at startup. The full skill body is fetched only when your prompt matches the description. This means:

• A 500-line deployment checklist skill costs near-zero tokens until you ask about deployments.
• You can maintain 50+ skills without bloating every conversation.
• Skills are portable: the same .cursor/skills/ folder works in Cursor today and any future tool that adopts the agentskills.io spec.
• Skills can bundle executable scripts and reference files that load incrementally during execution.

The right mental model: AGENTS.md is a standing order, a skill is a specialist you call when you need them.

How the agent discovers and uses a skill

The agent works in three stages:

Stage 1 — Discovery: When the agent starts, it scans the skills directory and reads only the YAML frontmatter (name and description) from every SKILL.md. This is a tiny token cost even with dozens of skills.

Stage 2 — Activation: When you send a prompt, the agent compares your request against the description of each skill. If it matches, the full SKILL.md body is loaded and injected into the LLM context alongside your prompt.

Stage 3 — Execution: The LLM now has the skill instructions and follows them. If the skill references scripts or resource files, those are fetched or run on demand as the task progresses.

Creating a custom skill

First create the directory and file:

mkdir -p .agent/skills/frontend-component
touch .agent/skills/frontend-component/SKILL.md

The SKILL.md needs YAML frontmatter for discovery, followed by the instructions:

---
name: frontend-component
description: Use this skill when building or modifying a UI component.
---
# Frontend component skill example
1. Use our internal CSS Modules system. Do not use Tailwind CSS.
2. Ensure every interactive element includes an `aria-label`.
3. Read `tokens.json` in this directory to get the exact hex codes for our brand colors before styling.
4. After implementation, run `npm run lint:css` to verify compliance.

The description field is what the agent pattern-matches against your prompt at discovery time. Make it specific. "Use this skill when building or modifying a UI component" is better than "frontend skill" because the agent needs enough context to trigger it correctly and to not trigger it when it's irrelevant.

How skills are invoked

Skills can be triggered in two ways: explicitly by the user or automatically by the agent.

Manual invocation with /

Most AI tools support a slash-command shortcut. Type / followed by the skill name and the agent immediately loads that skill's full body, regardless of whether your prompt text would have matched it automatically.

/frontend-component Build the UserCard component
/test Write tests for the payment module
/seo-blog Add meta tags to the about page

This is useful when you know exactly which workflow you want. The agent skips the pattern-matching step and jumps straight to execution. It is also a good safety net for skills with broad descriptions that might not trigger consistently.

Automatic discovery

When you write a natural-language prompt without a slash command, the agent compares your request against the description field of every skill in the directory. If the description is a strong semantic match, the skill activates automatically.

# User types:
"I need to build a responsive navigation bar"

# Agent matches description:
"Use this skill when building or modifying a UI component."
# → SKILL.md body is loaded automatically

The quality of the description determines how reliable automatic discovery is. A vague description like "frontend skill" will either fire too broadly or miss the right moments. A precise description scoped to a specific action prevents unintended activations.

Invocation modeWhen to use/skill-name promptYou know exactly which skill appliesNatural languageConversational workflows where the agent picks the right tool

Example: an SEO skill for website development

Here is a practical skill you would add when building or maintaining a content-heavy website. Save it at .github/skills/seo-blog/SKILL.md (or the equivalent path for your tool):

---
name: seo-blog
description: Use this skill when adding, reviewing, or optimising SEO metadata for a web page or blog post, including meta tags, Open Graph tags, structured data, and sitemap entries.
---

# SEO skill

## Checklist for every page
1. **Title tag** - 50-60 characters, primary keyword near the front.
2. **Meta description** - 120-158 characters, includes the keyword and a clear value statement.
3. **Open Graph tags** - og:title, og:description, og:image (1200×630 px), og:url.
4. **Twitter/X card** - twitter:card, twitter:title, twitter:description, twitter:image.
5. **Canonical URL** - set link rel="canonical" on every page to prevent duplicate indexing.
6. **Structured data** - add JSON-LD Article schema for blog posts, WebPage for static pages.
7. **Sitemap** - verify the page is included in sitemap.xml with the correct lastmod date.
8. **Image alt text** - every img tag must have a descriptive alt attribute.
## Naming conventions
- Slug format: kebab-case, maximum 5 words, keyword first. Example: spring-boot-caching-guide.
- Keep slugs stable after publication; redirects cost crawl budget.
## Validation
After making changes, run:
  npm run build && npx lighthouse http://localhost:3000/your-page --only-categories=seo
Target score: 95 or above. Fix any flagged issues before merging.

Invoke this skill manually when writing a new post (/seo-blog Add metadata to the Java caching guide) or let it fire automatically whenever your prompt mentions SEO, meta tags, or Open Graph.

Creating skills for each stage of SDLC

Here are a few examples of skills you can create for each stage of SDLC:

Brainstorming and definition (/spec)

Instruct the agent to interview you before writing code. It clarifies edge cases, API boundaries, and performance constraints, then outputs a strict technical specification.

Planning (/plan)

The agent takes the specification and breaks it down into small, verifiable units, mapping out exact file changes.

Coding (/frontend or /backend)

Enforce use of specific internal component libraries and architectural rules. This prevents the LLM from generating generic, outdated solutions.

Testing (/test)

Instruct the agent to write unit tests, run the test suite via a shell command, and debug failures before finalizing the feature.

Security risks

Treat skills like third-party dependencies. Because Agent Skills give LLMs the ability to execute scripts and read files, a malicious .py script could exfiltrate environment variables or run destructive bash commands.

⚠️ Always audit skills from external sources before adding them to your .agent/skills directory. Check network access settings if you run agents in a sandbox.

Skill repositories

Instead of writing everything from scratch, there are many open source repositories that we can use to get started. I have used few from the below recently.

• addyosmani/agent-skills: Production-grade engineering skills enforcing the Test Pyramid and trunk-based development.
• anthropics/skills: The official Anthropic repository demonstrating progressive disclosure with workflows for MCP servers and PDFs.
• VoltAgent/awesome-agent-skills: Community curation of custom agent skills and framework-agnostic tools.

Start with the Anthropic examples to understand baseline capabilities, then layer in the engineering constraints from Addy Osmani’s repository.

🔗 Blog 🔗 LinkedIn 🔗 Medium 🔗 Github

Originally published at https://codewiz.info.

In modern microservices architectures, we often run multiple instances of our applications to ensure high availability and scalability. While this is great for performance, it introduces a new set of challenges when it comes to managing shared resources.

One of the most common challenges is ensuring that a specific critical section of code is executed by only one instance at a time. This is where distributed locking comes into play.

The problem: The double booking nightmare

Imagine you are building a movie ticket booking application. You have a TicketService with a method bookSeat(String seatId, String userId).

If you have a single instance of your application, you might use Java’s synchronized keyword or a ReentrantLock to ensure that two users don't book the same seat simultaneously.

// Works fine for a Single Instance
public synchronized void bookSeat(String seatId, String userId) {
    if (isSeatAvailable(seatId)) {
        reserverSeat(seatId, userId);
    }
}

However, in a distributed environment with multiple instances of the service running (e.g., on Kubernetes), synchronized only works within a single JVM.

Since Instance A and Instance B don’t share memory, their local locks are unaware of each other. User A and User B could both check availability at the exact same moment, see the seat as “Available”, and both proceed to book it. Result: Double Booking.

The solution: Distributed locking with Redis

To solve this, we need a lock that is external to our application instances — a shared source of truth. Redis is an excellent choice for this. It processes commands sequentially (single-threaded), ensuring atomic operations. It is extremely fast because it runs in-memory, and it supports key expiration, which is crucial for preventing deadlocks.

How it works

The algorithm requires acquiring a lock by trying to set a locking key in Redis (e.g., lock:seat:1A). If the key sets successfully, you have the lock and can proceed. If the key already exists, someone else has the lock, so you must wait or fail. When you finish, you release the lock by deleting the key.

Key concepts

Two core Redis features make this work. First, the SETNX (SET if Not eXists) command. This operation only sets the key if it does not already exist, which is exactly the behavior we need to acquire a lock atomically.

Second, we need expiration (TTL). What if the service crashes after acquiring the lock but before releasing it? The lock would stay forever, creating a deadlock. To prevent this, we set a Time-To-Live (TTL) on the lock key so the database automatically releases it if the application dies.

Implementation in Spring Boot

Here is how we implement a robust distributed lock using RedisTemplate.

1. Dependencies

Add the Redis starter to your pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

2. RedisLock utility

We’ll create a component to handle the locking logic.

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;

import java.time.Duration;
import java.util.concurrent.TimeUnit;
@Component
public class RedisLock {
    private final StringRedisTemplate redisTemplate;
    public RedisLock(StringRedisTemplate redisTemplate) {
        this.redisTemplate = redisTemplate;
    }
    /**
     * Tries to acquire the lock.
     * @param key The unique key for the resource (e.g., "lock:seat:123")
     * @param timeout The duration for which the lock should be held (TTL)
     * @return true if lock is acquired, false otherwise
     */
    public boolean acquireLock(String key, Duration timeout) {
        // SET key value NX EX timeout
        Boolean success = redisTemplate.opsForValue()
                .setIfAbsent(key, "LOCKED", timeout);
        return Boolean.TRUE.equals(success);
    }
    /**
     * Releases the lock by deleting the key.
     * @param key The unique key to release
     */
    public void releaseLock(String key) {
        redisTemplate.delete(key);
    }
}

Note: setIfAbsent corresponds to the atomic SET ... NX EX ... command in Redis. It ensures we set the key and the expiry in one atomic operation.

3. Ticket booking service

Now, let’s use this lock in our TicketService.

import org.springframework.stereotype.Service;
import java.time.Duration;

@Service
public class TicketService {
    private final RedisLock redisLock;
    private final BookingRepository bookingRepository;
    public TicketService(RedisLock redisLock, BookingRepository bookingRepository) {
        this.redisLock = redisLock;
        this.bookingRepository = bookingRepository;
    }
    public void bookSeat(String seatId, String userId) {
        String lockKey = "lock:seat:" + seatId;
        
        // Define how long we hold the lock. 
        // Should be longer than the expected execution time.
        Duration lockTimeout = Duration.ofSeconds(10); 
        try {
            // 1. Try to acquire the lock
            if (redisLock.acquireLock(lockKey, lockTimeout)) {
                
                // 2. Critical Section
                // Double check availability in DB just to be sure
                if (isSeatAvailable(seatId)) {
                    // Simulate processing (e.g., payment)
                    processPayment(); 
                    
                    reserveSeatInDb(seatId, userId);
                    System.out.println("Seat " + seatId + " booked for " + userId);
                } else {
                    throw new RuntimeException("Seat already booked!");
                }
                
            } else {
                // 3. Failed to acquire lock
                throw new RuntimeException("Seat is currently being booked by someone else. Please try again.");
            }
        } finally {
            // 4. Always release the lock!
            redisLock.releaseLock(lockKey);
        }
    }
    private boolean isSeatAvailable(String seatId) {
        // Logic to check DB
        return true;
    }
    private void reserveSeatInDb(String seatId, String userId) {
        // Logic to save booking
    }
    
    private void processPayment() {
         try {
            Thread.sleep(2000); // Simulate network call
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

Improving the solution

The implementation above functions well, but production systems have edge cases that quickly complicate things.

Consider accidental releases. What if Instance A acquires a lock but takes too long processing, causing the lock to expire? Instance B then acquires the lock. Finally, Instance A finishes its work and deletes the key. Instance A just deleted Instance B’s lock! The fix here is to store a unique UUID as the value of the lock key. When releasing, you check if the value matches your UUID before deleting. This requires a Lua script to remain atomic.

Then there is Redis failover. If the Redis master crashes after a lock is acquired but before it replicates to the replica, consistency goes out the window. You can mitigate this using the Redlock algorithm or by ensuring strong consistency in your Redis cluster, but it adds significant operational overhead.

Production recommendation: Redisson

For production applications, don’t reinvent the wheel. Use Redisson, a popular Redis client for Java that implements java.util.concurrent.locks.Lock backed by Redis. It handles:

• Automatic lease extension (Watchdog).
• Correct atomic release logic.
• Wait strategies (spin locks, pub/sub for release events).

Here is how simple it is with Redisson:

RLock lock = redissonClient.getLock("lock:seat:" + seatId);
try {
    if (lock.tryLock(1, 10, TimeUnit.SECONDS)) {
        // Critical section
    }
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
} finally {
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

Conclusion

Distributed locking ensures data consistency in microservices, and Redis provides a fast, reliable foundation for implementing these locks using atomic operations and key expirations. However, building a custom lock requires careful handling of edge cases like accidental releases and failovers. Rather than writing this logic from scratch, use libraries like Redisson that handle lease management and failover automatically. By managing your critical sections correctly, you avoid double booking nightmares down the road.

🔗 Blog 🔗 LinkedIn 🔗 Medium 🔗 Github

Originally published at https://codewiz.info.

Every Spring Boot project that touches a database hits this question sooner or later: Flyway or Liquibase?

I’ve used both across different teams and projects over the years. Both are battle-tested, both integrate with Spring Boot out of the box, and both get the job done. But I keep reaching for Flyway. Not because Liquibase is bad (it isn’t), but because Flyway’s philosophy aligns better with how I think about database changes.

Let me walk through the real differences, the stuff that actually matters day-to-day, and why I land where I do.

You can read the same blog here on my website also

What both tools actually do

Before comparing, let’s be clear about the shared goal. Both Flyway and Liquibase:

• Track which schema changes have been applied to a database
• Run pending migrations automatically on application startup
• Store migration history in a metadata table (flyway_schema_history for Flyway, DATABASECHANGELOG for Liquibase)
• Integrate with Spring Boot via auto-configuration (just add the dependency and it works)
• Support all major databases: PostgreSQL, MySQL, Oracle, SQL Server, H2, etc.

The difference is in how they approach migrations.

Flyway: SQL files, naming conventions, done

Flyway’s approach is dead simple. You write SQL files, name them with a version prefix, and drop them in a folder. That’s it.

src/main/resources/db/migration/
├── V1__create_users_table.sql
├── V2__add_email_column.sql
├── V3__create_orders_table.sql
└── V4__add_index_on_email.sql

Each file contains plain SQL:

-- V1__create_users_table.sql
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    username VARCHAR(100) NOT NULL UNIQUE,
    created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

Flyway scans the folder, checks which versions have already been applied (via flyway_schema_history), and runs the new ones in order. The naming convention ( V{version}__{description}.sql) is the entire configuration.

Spring Boot setup? One dependency and zero configuration:

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>

Spring Boot auto-detects the db/migration folder and runs Flyway on startup. You don't even need to add a single property unless you want to customize something.

Liquibase: Changelogs, changesets, and format choices

Liquibase takes a different approach. Instead of raw SQL files, you define changes in a changelog file using XML, YAML, JSON, or SQL. Each change is wrapped in a changeset with an author and an ID.

Here’s the same users table creation in Liquibase XML:

<!-- db/changelog/db.changelog-master.xml -->
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
        http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-latest.xsd">

    <changeSet id="1" author="user1">
        <createTable tableName="users">
            <column name="id" type="BIGSERIAL" autoIncrement="true">
                <constraints primaryKey="true" nullable="false"/>
            </column>
            <column name="username" type="VARCHAR(100)">
                <constraints nullable="false" unique="true"/>
            </column>
            <column name="created_at" type="TIMESTAMP" defaultValueComputed="NOW()">
                <constraints nullable="false"/>
            </column>
        </createTable>
    </changeSet>

</databaseChangeLog>

Or in YAML:

databaseChangeLog:
  - changeSet:
      id: 1
      author: user1
      changes:
        - createTable:
            tableName: users
            columns:
              - column:
                  name: id
                  type: BIGSERIAL
                  autoIncrement: true
                  constraints:
                    primaryKey: true
                    nullable: false
              - column:
                  name: username
                  type: VARCHAR(100)
                  constraints:
                    nullable: false
                    unique: true

Spring Boot setup for Liquibase:

<dependency>
    <groupId>org.liquibase</groupId>
    <artifactId>liquibase-core</artifactId>
</dependency>

By default, Spring Boot looks for db/changelog/db.changelog-master.yaml (or .xml).

The real differences that matter

Let me cut through the feature-matrix noise and focus on what actually impacts your daily workflow.

1. Migration format: SQL vs abstraction layer

This is the fundamental philosophical split.

Flyway says: “You know SQL. Write SQL.”

Liquibase says: “Describe what you want, and we’ll generate the right SQL for your database.”

Liquibase’s abstraction layer (createTable, addColumn, etc.) is genuinely useful if you deploy the same app against multiple database engines. If your app needs to run on both PostgreSQL and Oracle, writing createTable in XML is easier than maintaining two sets of SQL files.

But here’s the thing: most Spring Boot projects I’ve worked on target one database. We pick PostgreSQL (or MySQL, or whatever) and stick with it. In that world, the abstraction layer is overhead. I’d rather write the exact CREATE TABLE statement I want, with the exact PostgreSQL-specific features I need (BIGSERIAL, JSONB columns, partial indexes), than translate my intent through XML tags.

Flyway does support Java-based migrations for complex cases, and Liquibase lets you write raw SQL changesets too. But the defaults and conventions push you in opposite directions.

2. Readability in code review

This one matters more than people think.

When a teammate opens a PR with a new Flyway migration, I see SQL. I can immediately tell what’s changing. I can mentally run the statement and think about locking implications, index strategies, or data type choices.

-- V12__add_status_to_orders.sql
ALTER TABLE orders ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'PENDING';
CREATE INDEX idx_orders_status ON orders(status);

That’s two lines. I know exactly what’s happening.

The Liquibase equivalent:

<changeSet id="12" author="ratheesh">
    <addColumn tableName="orders">
        <column name="status" type="VARCHAR(20)" defaultValue="PENDING">
            <constraints nullable="false"/>
        </column>
    </addColumn>
    <createIndex indexName="idx_orders_status" tableName="orders">
        <column name="status"/>
    </createIndex>
</changeSet>

It’s more verbose, and the XML ceremony makes it harder to scan quickly. In a busy PR with application code changes alongside migration changes, the Flyway version wins for me every time.

3. Rollback support

This is where Liquibase has a genuine edge, and I want to be honest about it.

Liquibase supports automatic rollback for many operations. If a createTable was applied, it knows to DROP TABLE on rollback. For operations where it can't auto-generate a rollback, you can define custom rollback SQL within the changeset.

<changeSet id="5" author="ratheesh">
    <addColumn tableName="users">
        <column name="phone" type="VARCHAR(20)"/>
    </addColumn>
    <rollback>
        <dropColumn tableName="users" columnName="phone"/>
    </rollback>
</changeSet>

Flyway’s community edition doesn’t support rollback at all. The paid “Teams” edition does, but honestly? I’ve never relied on automated rollback in production anyway.

Here’s my take: if a migration goes wrong in production, I don’t want to “undo” it automatically. I want to understand what happened, assess data impact, and write a forward migration to fix it. Rolling back a CREATE TABLE is fine, but rolling back an ALTER TABLE that just ran against 50 million rows? That needs human judgment, not an automated reverse script.

So while Liquibase’s rollback support is technically better, I don’t consider it a dealbreaker.

4. Spring Boot integration

Both tools have first-class Spring Boot support, but Flyway’s is slightly more frictionless.

Flyway with Spring Boot:

# application.properties - honestly, you might not need ANY of these
spring.flyway.enabled=true
spring.flyway.locations=classpath:db/migration
# That's it. Both lines above are the defaults anyway.

Liquibase with Spring Boot:

spring.liquibase.enabled=true
spring.liquibase.change-log=classpath:db/changelog/db.changelog-master.yaml

The difference is minimal, but Flyway’s convention of “just drop SQL files in db/migration" means there is genuinely zero configuration needed. No master changelog file to maintain, no changeset IDs to manage.

5. Learning curve

I’ve onboarded junior developers onto both tools. With Flyway, the conversation goes:

“Write your SQL, name the file V{next_number}__description.sql, put it in db/migration. Done."

With Liquibase, there’s more to explain: changelog format choices (XML? YAML? SQL?), changeset structure, author/ID conventions, preconditions, contexts, labels. It’s more powerful, but newcomers have more to absorb.

Where Liquibase genuinely wins

I don’t want to pretend Flyway is better at everything. Liquibase has real strengths:

Multi-database support. If you ship a product that customers deploy on their choice of database (PostgreSQL, MySQL, Oracle, SQL Server), Liquibase’s abstraction layer saves you from maintaining separate SQL scripts per database. Flyway can do this with location overrides, but it’s more manual.

Preconditions. Liquibase can check if a table exists before trying to create it, or if a column is a certain type before altering it. This is useful for migrations that might run against databases in varying states (common in large enterprise environments).

<changeSet id="10" author="ratheesh">
    <preConditions onFail="MARK_RAN">
        <not><tableExists tableName="audit_log"/></not>
    </preConditions>
    <createTable tableName="audit_log">
        <!-- columns -->
    </createTable>
</changeSet>

Contexts and labels. Need to apply certain migrations only in dev but not prod? Liquibase has built-in support for this with contexts. Flyway can achieve similar results, but it's not as clean.

Diff and changelog generation. Liquibase can compare two database schemas and auto-generate a changelog of differences. This is helpful when reverse-engineering an existing database into version control for the first time.

Where Flyway wins (and why I pick it)

Simplicity. There is almost nothing to learn. SQL files, naming convention, done. The cognitive overhead is close to zero.

Transparency. What you see is what’s executed. No abstraction layer translating your intent into SQL behind the scenes. When something goes wrong, there’s no question about what SQL actually ran.

Speed of authoring. Writing a SQL file is faster than wrapping the same logic in XML/YAML tags. Over hundreds of migrations across a project’s lifetime, this adds up.

Clean Git history. Each migration is a standalone file. Git blame and log work exactly as you'd expect. With Liquibase's single-changelog-file approach (or even with includes), the history is messier.

Team convention. Since there’s only one way to do things in Flyway (SQL files with version prefixes), there are fewer debates. With Liquibase, teams argue about XML vs YAML, single changelog vs multiple files, when to use preconditions, etc.

A side-by-side Spring Boot setup

For anyone who wants to quickly try both, here’s the minimum setup for each.

Flyway:

pom.xml:    flyway-core dependency
            (flyway-database-postgresql if using PG)
folder:     src/main/resources/db/migration/
file:       V1__init.sql
config:     nothing required

Liquibase:

pom.xml:    liquibase-core dependency
folder:     src/main/resources/db/changelog/
file:       db.changelog-master.yaml (+ included changelogs)
config:     nothing required (Spring Boot defaults work)

When to pick Liquibase instead

Pick Liquibase when:

• Your application deploys against multiple database vendors and you want one set of migration definitions
• You’re in a heavily regulated environment where rollback support, preconditions, and labels are required by policy
• You’re working with customers who manage their own database and migrations need to be resilient to schema drift
• You need to reverse-engineer an existing database into version-controlled changelogs

When to pick Flyway (most of the time)

Pick Flyway when:

• You target a single database (which is the majority of Spring Boot apps)
• You value simplicity and want the lowest possible learning curve
• Your team is comfortable writing SQL directly
• You want maximum transparency in code reviews
• You don’t need automated rollback (forward-only migrations is your strategy)

My honest take

Both Flyway and Liquibase are production-ready tools used by thousands of teams. You won’t regret picking either one.

But I keep choosing Flyway because it stays out of my way. I write SQL every day. I don’t need an abstraction layer to write ALTER TABLE. The naming convention enforces order without any configuration. And when I review a teammate's migration PR, I see exactly what will happen to the database. No translation needed.

Liquibase is the better choice when your problem space genuinely requires its advanced features (multi-database, preconditions, policy-driven rollbacks). But for the typical Spring Boot app talking to one PostgreSQL instance? Flyway is all you need.

Pick the tool that matches your team’s reality, not the one with the longest feature list.

📚 Related: If you’re working with Spring Data JPA alongside your migrations, check out the Spring JPA cheat sheet and Database indexes deep dive.

🔗 Blog 🔗 LinkedIn 🔗 Medium 🔗 Github

Originally published at https://codewiz.info.

Spring AI is the most popular AI framework for building agents in JVM ecosystem. It seamlessly integrates with the rest of the Spring ecosystem and makes it really easy to integrate with all major LLMs.

In this short tutorial, we will build a Stock Advisor Agent and learn key building blocks of Spring AI.

We’ll cover the below concepts:

• Chat Client: The main interface for talking to LLMs.
• Tools (Function Calling): Giving the AI ability to execute code.
• Memory: Letting the AI remember context across a conversation.
• Advisors: Intercepting requests to add logic (like memory or logging).
• Structured Output: Getting strict JSON objects back, not just text.

You can also read the same blog on my website here

Setting Up the Project

We’ll start with a Spring Boot project. I’m using Java 25 here, but Java 17+ works fine. The key dependencies are spring-ai-starter-model-openai for the LLM interaction and spring-boot-starter-web for exposing our endpoints.

Dependencies

Here are the key dependencies in pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jdbc</artifactId>
    </dependency>
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-starter-model-openai</artifactId>
    </dependency>
</dependencies>

You can find the full pom.xml here.

Configuration

Make sure you have your OPENAI_API_KEY set in your environment variables. Spring AI will pick this up automatically.

Here is the application.properties file:

Here we are using OpenAI model. You can also switch to any other model or even local LLMs by just changing the dependency and adding the configuration for the model.

You can find the full application.properties here.

spring.application.name=stockagent

spring.ai.openai.chat.api-key=${OPENAI_API_KEY}

# PostgreSQL Database Configuration
spring.datasource.url=jdbc:postgresql://localhost:5432/stock-agent-db
spring.datasource.username=stock-agent-user
spring.datasource.password=secret
spring.datasource.driver-class-name=org.postgresql.Driver

# Schema Initialization
spring.sql.init.mode=always
spring.sql.init.schema-locations=classpath:schema.sql

# Stock API Configuration
stock.api.key=${STOCK_API_KEY}

The Chat Client: Talking to the Brain

The heart of our agent is the ChatClient. Think of it as the fluent API wrapper that makes interacting with the AI model much smoother than raw HTTP calls.

It handles the heavy lifting of:

• Prompt Management: structuring the messages sent to the AI.
• Advisors: Intercepting requests to add logic (like memory or logging).
• Model Switching: You can swap OpenAI for Claude or Gemini without code changes.

System vs. User Prompts

In the configuration below, you’ll see two types of messages:

1. System Prompt (defaultSystem): This sets the "Persona" and "Rules". It's like the job description for the AI. We tell it: "You are a stock advisor," "Use Markdown," and "Always ask for confirmation." This context persists across every interaction.
2. User Prompt: This is the specific input from the user (e.g., “Buy Apple stock”). It triggers the immediate action.

Here is how we configure it in StockAdvisorAssistant.java:

@Service
public class StockAdvisorAssistant {

    private final ChatClient chatClient;
    private static final String SYSTEM_MESSAGE = """
            You are a polite stock advisor assistant who provides advice based on 
            the latest stock price, company information and financial results.
            When you are asked to create a stock order, ask for a confirmation before creating it.
            In the confirmation message, include the stock symbol, quantity, price, and current market price.
            All your responses should be in markdown format.
            When you are returning a list of items like position, orders, list of stocks etc, return them in a table format.
            """;

    public StockAdvisorAssistant(ChatClient.Builder chatClientBuilder) {
        this.chatClient = chatClientBuilder
                .defaultSystem(SYSTEM_MESSAGE)
                .build();
    }
    
    // ... methods ...
}

Notice the system message. I found that being very specific about formatting (like “return them in a table format”) saves a ton of parsing headaches later. We inject the ChatClient.Builder which makes testing easier and allows Spring to pre-configure defaults.

Giving the Agent Tools

An AI that can’t access data is just a fancy text generator. Tools (also known as Function Calling in OpenAI land) is one of the approaches to bridge this gap.

In Spring AI, any Java method can be a tool. You just annotate it with @Tool.

Here’s our StockInformationService that fetches real data using API from FMP:

@Service
public class StockInformationService {

    private static final Logger log = LoggerFactory.getLogger(StockInformationService.class);
    // ... dependencies ...

    @Tool(description = "Returns the stock price for the given stock symbol")
    public String getStockPrice(String stockSymbol) {
        log.info("Fetching stock price for stock symbols: {}", stockSymbol);
        return fetchData("/quote?symbol=" + stockSymbol);
    }

    @Tool(description = "Returns the company profile for the given stock symbol.")
    public String getCompanyProfile(String stockSymbol) {
        // implementation fetching from external API
        return fetchData("/profile?symbol=" + stockSymbol);
    }
    
    // ... other tools ...
}

The description in the @Tool annotation is critical. This is what the LLM sees to decide when and how to call this function. If you leave it vague, the model might hallucinate parameters or ignore the tool entirely.

We also have a StockOrderService to perform actions for storing and retrieving stock orders in the database:

@Service
public class StockOrderService {
    
    private final StockOrderRepository stockOrderRepository;

    @Tool(description = "Creates a new stock order. Input: StockOrder object with symbol, quantity, price, and orderType (BUY or SELL)")
    public StockOrder createOrder(StockOrder order) {
        // Saves to database using Spring Data JDBC
        return stockOrderRepository.save(order);
    }
}

Registering the Tools

Now we need to tell the ChatClient about these tools. We do this in our configuration class:

@Configuration
public class AssistantConfiguration {

    @Bean
    public ChatClient.Builder chatClientBuilder(org.springframework.ai.chat.model.ChatModel chatModel,
            ChatMemory chatMemory, StockInformationService stockInformationService, StockOrderService stockOrderService) {
        return ChatClient.builder(chatModel)
                .defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build())
                .defaultTools(stockInformationService, stockOrderService);
    }
}

By calling .defaultTools(stockInformationService, stockOrderService), we make these beans available to every prompt sent by this client. The Spring AI handles the serialization of arguments and execution of the method automatically.

Memory: Maintaining Context

If you ask “What’s the price of Apple?” and then follow up with “Buy 10 shares”, a stateless LLM will ask “Buy 10 shares of what?”.

To fix this, we need conversational memory. Spring AI handles this via Advisors.

What are Advisors?

Advisors in Spring AI are like interceptors or “middleware” for your Chat Client. They sit between your application and the AI model, allowing you to modify the request or response.

Common uses for Advisors include:

• Memory: Injecting past conversation history into the prompt (like we do here).
• RAG (Retrieval Augmented Generation): Finding relevant documents and adding them to the prompt context.
• Logging/Observability: inspecting tokens and latency.

In our case, we use MessageChatMemoryAdvisor to automatically attach the conversation history to every request.

In the configuration above, we added: .defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build())

We will configure a simple in-memory store that keeps the last 20 messages:

@Bean
public ChatMemory chatMemory() {
    return MessageWindowChatMemory.builder()
            .maxMessages(20)
            .build();
}

Now, when we call the chat client, we pass a conversationId to retrieve the correct history:

public String chat(String userMessage, String conversationId) {
    return chatClient.prompt()
            .user(userMessage)
            .advisors(a -> a.param(ChatMemory.CONVERSATION_ID, conversationId))
            .call()
            .content();
}

This simple addition makes the interaction feel human. The agent remembers we were talking about Apple stock without us repeating the ticker symbol.

Going Beyond In-Memory (Persistence)

In this example, we used MessageWindowChatMemory, which lives in the application's RAM. If you restart the server, the conversation is lost.

For production apps, you usually want to persist this history. Spring AI supports several options to store chat history externally without changing your memory advisor logic:

• JDBC Chat Memory: Stores conversation history in your relational database (PostgreSQL, MySQL).
• NoSQL Stores: Adapters available for Cassandra, MongoDB, etc.
• Vector Stores: You can even use vector databases to retrieve only the relevant past memories rather than the entire history (RAG-style memory).

You would simply swap the ChatMemory bean with a persistent implementation, and the rest of your agent code remains exactly the same.

Testing in Action

Now our agent is ready. We can test it by calling the chat url from browser or using curl or httpie.

But I’ve built a simple HTML frontend (included in the project source) to test our agent. Here is how the conversation flows:

You can access the frontend at `http://localhost:8080/index.html`.

Figure 1: The agent welcomes us and lists its capabilities.

Figure 2: We ask for the price of Apple (AAPL), and the agent calls the getStockPrice tool.

Figure 3: We ask to buy shares. Notice the agent asks for confirmation? That’s the system prompt in action.

Figure 4: Once confirmed, the agent calls createOrder and returns the transaction details.

Structured Output

Sometimes you don’t want a chat response; you want data you can use in your code. For example, if I ask for “3 stock picks for a growth strategy”, I want a JSON array, not a paragraph of text.

Spring AI handles this beautifully with the .entity() method.

public List<StockPick> getStockPicks(String strategy, int count) {
    return chatClient.prompt()
            .user(u -> u.text("Suggest {count} stock picks for a {strategy} portfolio. Return symbol, companyName, and brief rationale.")
                    .param("count", count)
                    .param("strategy", strategy))
            .call()
            .entity(new ParameterizedTypeReference<List<StockPick>>() {});
}

Under the hood, Spring AI injects strict format instructions into the prompt and parses the JSON response into your Java StockPick record. It's concise and type-safe.

Testing Structured Output

We can verify this endpoint using httpie:

http :8080/picks strategy==growth count==5

Response:

[
    {
        "symbol": "AAPL",
        "companyName": "Apple Inc.",
        "rationale": "Strong ecosystem, expanding services revenue, and continued innovation in hardware and AI drive robust top‑line growth."
    },
    {
        "symbol": "AMZN",
        "companyName": "Amazon.com, Inc.",
        "rationale": "Dominant e‑commerce platform combined with high‑margin cloud services (AWS) and expanding advertising business fuel long‑term revenue acceleration."
    },
    {
        "symbol": "NVDA",
        "companyName": "NVIDIA Corporation",
        "rationale": "Leader in GPU technology powering AI, data centers, gaming, and autonomous vehicles, with rapidly growing market share in high‑growth segments."
    },
    {
        "symbol": "TSLA",
        "companyName": "Tesla, Inc.",
        "rationale": "Rapidly scaling electric‑vehicle production, expanding energy storage and solar businesses, and strong brand positioning in the transition to clean transportation."
    },
    {
        "symbol": "SHOP",
        "companyName": "Shopify Inc.",
        "rationale": "Provides a scalable commerce platform for SMBs, benefiting from the shift to online retail and a growing ecosystem of merchants worldwide."
    }
]

Conclusion

The complete code for this project is available on my Github repo. It includes the full Docker Compose setup for PostgreSQL and the complete implementation of the tools.

Originally published at http://codewiz.info.

I’ve sat through hundreds of microservice interviews, both as a candidate and an interviewer. The questions that separate senior engineers from juniors aren’t about definitions-they’re about production experience or how well you can demonstrate your experience with distributed systems. Can you explain distributed transactions? Sure. But have you debugged a compensation transaction that failed halfway through?

Here are the top 10 microservice interview questions that actually matter. These aren’t theory questions-they’re designed to reveal your experience with distributed systems that handle real traffic, real failures, and real complexity.

1. How do you handle distributed transactions and data consistency across microservices?

This is where most candidates stumble. They know ACID transactions don’t work across services, but they can’t articulate the practical alternatives.

What They’re Really Asking:

Can you manage data consistency without a global transaction? In a monolith, you’d wrap everything in a single database transaction. In microservices, that approach fails because each service owns its own database. You need different strategies.

The Answer:

We can use the Saga pattern for long-running transactions that span multiple services. There are two approaches: orchestration and choreography.

Orchestration Pattern: A central orchestrator coordinates the workflow. It’s easier to understand and debug, but creates a single point of coordination. We can use this when we need explicit control over the transaction flow.

Java code example:

@Service
public class OrderOrchestrator {
    
    public void createOrder(OrderRequest request) {
        try {
            // Step 1: Reserve inventory
            InventoryResponse inventory = inventoryService.reserve(request.getItems());
            
            // Step 2: Process payment
            PaymentResponse payment = paymentService.process(request.getPayment());
            
            // Step 3: Create order
            Order order = orderService.create(request);
            
            // Step 4: Send confirmation
            notificationService.sendConfirmation(order);
            
        } catch (Exception e) {
            // Compensation logic
            compensate(request, e);
        }
    }
}

Choreography Pattern: Each service publishes events and reacts to events from others. No central coordinator. Better for scalability, but harder to debug. We can use this when services are loosely coupled and we want to avoid a coordination bottleneck.

The tradeoff is eventual consistency. You can’t guarantee immediate consistency across services. That’s okay for most business scenarios-users can tolerate a few seconds of delay for order confirmation.

Production Gotchas:

I’ve been bitten by compensation failures before. If your compensation logic itself fails, you’re in a partial state. Always make compensation operations idempotent. Also, ensure your saga steps are idempotent-network retries can cause duplicate executions.

2. Explain your approach to inter-service communication. When would you use synchronous vs asynchronous patterns?

This question reveals whether you understand the fundamental tradeoffs of distributed systems. Every communication pattern has consequences.

What They’re Really Asking:

Do you know when to use REST vs message queues? Can you explain why one approach might cascade failures while the other doesn’t?

The Answer:

We can choose synchronous communication (REST, gRPC) when we need immediate responses and can tolerate tight coupling. Asynchronous communication (Kafka, RabbitMQ) when we need resilience and can accept eventual consistency.

Synchronous Communication (REST/gRPC):

We can use REST for user-facing operations where response time matters. When a user clicks “Place Order,” they need to know immediately if it succeeded. But synchronous calls create dependencies-if the payment service is down, orders can’t be placed.

@RestController
public class OrderController {
    
    @Autowired
    private PaymentServiceClient paymentClient;
    
    @PostMapping("/orders")
    public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
        // Synchronous call - blocks until response
        PaymentResponse payment = paymentClient.processPayment(request.getPayment());
        
        if (payment.isSuccessful()) {
            return ResponseEntity.ok(orderService.create(request));
        }
        throw new PaymentException("Payment failed");
    }
}

The catch? Cascading failures. If the payment service is slow, your order service becomes slow too. That’s why I always add timeouts and circuit breakers to synchronous calls.

Asynchronous Communication (Message Brokers):

We can use message queues when we want loose coupling and better fault tolerance. The order service publishes an “OrderCreated” event. Payment and inventory services consume it independently. If payment service is down, the order still gets created-payment happens eventually.

@Service
public class OrderService {
    
    @Autowired
    private KafkaTemplate<String, OrderEvent> kafkaTemplate;
    
    public Order createOrder(OrderRequest request) {
        Order order = orderRepository.save(new Order(request));
        
        // Fire and forget - doesn't wait for consumers
        kafkaTemplate.send("order-created", new OrderCreatedEvent(order));
        
        return order;
    }
}

The tradeoff is eventual consistency. Users might see their order before payment is confirmed. That’s fine for most scenarios, but you need clear UX patterns.

I’ve seen teams use synchronous calls everywhere “because it’s simpler.” Then production hits, and a single slow service brings down the entire system. The fix? Move non-critical paths to async.

📚 Related: Learn more about resilience patterns in Top Resilience Patterns in Microservices.

3. How do you implement service discovery in a dynamic microservices environment? How do you handle service unavailability?

Service discovery is one of those infrastructure concerns that seems simple until you’re debugging why service A can’t find service B at 3 AM.

What They’re Really Asking:

Do you understand how services find each other when IPs change constantly? Can you handle the edge cases?

The Answer:

We can use client-side service discovery with a service registry like Consul or Eureka. Services register themselves on startup and deregister on shutdown. Clients query the registry to find available instances.

Service Registry Pattern:

Each service registers its network location (IP + port) when it starts. The registry maintains a list of healthy services. Clients query the registry periodically to get fresh service instances.

Handling Service Unavailability:

The registry marks services as unhealthy when health checks fail. But clients might have cached stale instances. I always implement retry logic with exponential backoff and failover to different instances.

For production, we can use client-side load balancing (Ribbon or Spring Cloud LoadBalancer) that automatically handles instance selection and retries. We should also configure timeouts shorter than the registry’s health check interval-if a service becomes unhealthy, clients stop calling it quickly.

Production Gotchas:

DNS caching is the silent killer. Java’s default DNS TTL is infinite, meaning clients cache IP addresses forever. If a service instance dies and a new one takes its IP, clients might keep hitting the old IP. I always set networkaddress.cache.ttl to 30 seconds in production.

Also, watch out for the thundering herd problem. When a service comes back online, all clients try to connect simultaneously. Implement staggered retry with jitter to spread the load.

In Kubernetes environments, we can use built-in service discovery. Kubernetes DNS automatically resolves service names to IPs, and endpoints are updated dynamically. Simpler than running a separate registry.

📚 Related: Explore more system design patterns in Top 15 System Design Patterns.

4. Describe your strategy for monitoring and observability in a distributed system. How do you trace a request across multiple services?

Observability is what keeps you sane in production. Without it, debugging distributed systems is like searching for a needle in a haystack blindfolded.

What They’re Really Asking:

Can you debug a request that spans 10 services? Do you understand correlation IDs and distributed tracing?

The Answer:

We can implement the three pillars of observability: metrics, logs, and traces. Each serves a different purpose, and you need all three.

Metrics (What’s happening now):

We can use Prometheus for metrics collection. Key metrics to track: request rate, latency percentiles (p50, p95, p99), error rate, and business metrics like orders per second. Dashboards in Grafana provide real-time visibility.

The trick is choosing the right metrics. Too many metrics create noise. Too few and you miss critical issues. We can focus on SLOs-if we promise 200ms p95 latency, that’s what we monitor.

Logs (What happened):

Centralized logging with correlation IDs. Every request gets a unique correlation ID that propagates through all service calls. When something breaks, we can grep for that ID and see the entire request flow.

We can use structured logging (JSON format) to query logs effectively. Tools like ELK stack or Loki make searching millions of log lines manageable.

Distributed Tracing (Why it’s slow):

Tracing shows the exact path a request takes through services and where time is spent. We can use OpenTelemetry with Jaeger or Zipkin.

The key is trace context propagation. Each service adds itself to the trace and forwards the trace context to downstream services. At the end, we get a complete timeline showing that 80% of the request time was spent in the payment service database query.

Production Gotchas:

Sampling is critical. You can’t trace every request-it’s too expensive. We can sample 1% of requests normally, but 100% during incidents. Also, trace context propagation can break if you use async processing. Make sure to pass trace context through message headers.

Alert fatigue is real. I only alert on metrics that require immediate action. Everything else goes to dashboards. If you get 50 alerts per hour, you’ll start ignoring them all.

5. What is the Circuit Breaker pattern, and can you describe a production scenario where you implemented it?

This question tests whether you understand failure modes in distributed systems. Circuit breakers prevent cascading failures-they’re essential in production.

What They’re Really Asking:

Have you experienced cascading failures? Do you understand when to fail fast vs retry?

The Answer:

A circuit breaker is like an electrical circuit breaker-it stops current flow when there’s too much load. In software, it stops calling a failing service to prevent cascading failures.

The circuit has three states: Closed (normal operation), Open (failing, reject requests immediately), and Half-Open (testing if service recovered).

How It Works:

We can configure a failure threshold-say, 50% failures in the last 100 requests. When threshold is breached, the circuit opens. All requests fail fast without calling the service. After a timeout period, the circuit moves to half-open and allows one test request. If it succeeds, the circuit closes. If it fails, it opens again.

Sample Code:

@Service
public class PaymentServiceClient {
    
    @Autowired
    private RestClient restClient;
    
    @CircuitBreaker(name = "payment-service", fallbackMethod = "processPaymentFallback")
    @Retry(name = "payment-service")
    public PaymentResponse processPayment(PaymentRequest request) {
        return restClient.post()
            .uri("http://payment-service/process")
            .contentType(MediaType.APPLICATION_JSON)
            .body(request)
            .retrieve()
            .body(PaymentResponse.class);
    }
    
    public PaymentResponse processPaymentFallback(PaymentRequest request, Exception e) {
        // Fallback: queue payment for later processing
        return new PaymentResponse()
            .status("QUEUED")
            .message("Payment queued due to service unavailability");
    }
}

Production Gotchas:

Don’t set thresholds too aggressively. If you open the circuit after 5% failures, you’ll open it during normal blips. Also, half-open state is tricky-if multiple requests hit during half-open, you might close the circuit prematurely. Most libraries handle this, but it’s worth understanding.

I’ve also seen teams forget fallback logic. Opening the circuit is good, but if you have no fallback, you’re just failing in a different way. Always design fallback behavior.

📚 Related: Learn more about implementing circuit breakers and other resilience patterns in Top Resilience Patterns in Microservices.

6. How do you handle API versioning and backward compatibility in microservices? What’s your deployment strategy?

This question separates engineers who’ve shipped breaking changes in production from those who haven’t. Versioning seems straightforward until you realize you’ve got 50 services depending on service A’s API, and service A needs to change.

What They’re Really Asking:

Have you broken production by deploying an incompatible API change? Do you understand the different versioning strategies and when each makes sense?

The Answer:

Versioning refers to the practice of managing changes to APIs so that existing clients continue to work while new features or breaking changes are introduced. It’s essential for evolving microservices without disrupting running systems, especially when multiple teams or clients depend on your APIs. Basically it is about running multiple versions of the same API side by side.

There are several techniques for API versioning:

1. URI Path Versioning:
Include the version number in the API path (e.g.,/api/v1/orders). This makes it clear which version is being used and allows multiple versions to coexist.

2. Header Versioning:
Clients specify the desired API version in a custom HTTP header, such as Accept-Version: v2. This keeps URLs cleaner and can make versioning less visible to end-users.

3. Content Negotiation:
The API version is embedded in the Accept or Content-Type headers using MIME types (e.g., application/vnd.myservice.v2+json). This decouples versioning from URLs but can be harder to discover and debug.

4. Query Parameter Versioning:
Clients provide a version as a query parameter (e.g.,/orders?version=2). While easy to implement, this approach is less common for APIs serving external clients.

Each technique has trade-offs in terms of discoverability, cacheability, and tooling support. The choice largely depends on team preferences, consumer needs, and the nature of the API. Whichever technique is chosen, the key is to ensure backward compatibility so that existing clients are not broken by new releases.

Backward Compatibility:

The golden rule: add, don’t remove. When introducing v2, keep v1 running. Never remove fields-deprecate them instead. Clients migrate at their own pace.

Deployment Strategy:

Deploy v2 alongside v1, not replacing it. Run both versions simultaneously during migration. For internal services, use canary deployments. External APIs require explicit versioning since we don’t control client upgrade schedules.

Production Gotchas:

Always version breaking changes-never change response structures in place. Maintain at most two versions (current and previous). Watch out for transitive dependencies-if service A calls service B (v1) and service B upgrades to v2, service A might break.

📚 Related: Learn more about implementing API versioning in Spring Boot in A Developer’s Guide to API Versioning and Implementation in Spring Boot.

7. How do you ensure security in a microservices architecture, especially for service-to-service communication?

Security in microservices is harder than in monoliths because you’ve got network boundaries everywhere. A vulnerability in one service can expose the entire system if service-to-service communication isn’t secured properly.

What They’re Really Asking:

Do you understand the security implications of distributed systems? Have you implemented mTLS, service meshes, or other production-grade security patterns?

The Answer:

We can use mutual TLS (mTLS) for service-to-service communication. Each service presents a certificate, and both services verify each other’s identity. This prevents man-in-the-middle attacks and ensures only authorized services can communicate.

The challenge is certificate management. In Kubernetes, we can use cert-manager to automatically issue and rotate certificates from Let’s Encrypt or an internal CA. Without automation, certificate rotation becomes a nightmare. I’ve seen teams forget to rotate certificates and wake up to production outages when certificates expired.

For user-facing APIs, we can use OAuth 2.0 with JWT tokens. The API Gateway validates tokens and forwards them to services. Services trust the gateway and extract user context from the token. This pattern centralizes authentication while keeping services stateless.

API keys are fine for service-to-service calls in trusted environments, but they’re static secrets. Anyone with the key has access. I prefer certificates because they can be rotated without code changes and provide better audit trails.

The service mesh pattern is also used for security. Istio or Linkerd handle mTLS automatically, encrypting all service-to-service traffic without code changes. I’ve used Istio in production, and while the operational complexity is higher, the automatic security posture improvement is worth it for large deployments.

📚 Related: Learn how to secure service-to-service calls in depth with JWT and Spring Security in JWT Authentication with Spring 6 Security: Complete Guide.

8. What is eventual consistency, and how do you handle scenarios where your service needs strongly consistent data from another microservice?

This question tests whether you understand the fundamental tradeoffs of distributed systems. Eventual consistency isn’t a bug-it’s a feature you design for. But sometimes you need stronger guarantees.

What They’re Really Asking:

Do you understand CAP theorem in practice? Can you explain when eventual consistency is acceptable and when it isn’t? Have you built systems that need strong consistency across service boundaries?

The Answer:

Eventual consistency means that if I stop making updates, all services will eventually see the same data. There’s no guarantee of immediate consistency. If service A updates a customer’s balance, service B might not see that change for seconds or even minutes, depending on how you propagate updates.

Most business scenarios can tolerate eventual consistency. If I place an order, it’s fine if the inventory service updates a few seconds later. Users don’t need to see real-time inventory counts. If payment processing takes a moment, that’s acceptable. Eventual consistency gives you availability and partition tolerance, which are usually more important than immediate consistency.

But sometimes you need strong consistency. If I’m checking if a customer has sufficient balance before processing a payment, eventual consistency isn’t good enough. I need to know the current balance right now, not eventually.

The solution depends on where the data lives. If both services need strongly consistent data, we can use one of these patterns:

Pattern 1: Move the data into one service. If order service needs customer balance, maybe the order service should own customer balances. But this breaks service boundaries and creates tight coupling. We should avoid this unless the data naturally belongs together.

Pattern 2: Use distributed locks or transactions. We can use a distributed lock to ensure only one service updates customer balance at a time. This gives strong consistency but creates contention and potential deadlocks. The performance impact is significant, so we should only use this when absolutely necessary.

Pattern 3: Use a transactional outbox. When the payment service updates a balance, it writes the update to its database and also writes an event to an outbox table in the same transaction. A separate process reads the outbox and publishes events. The outbox ensures the event is published exactly once, giving eventual consistency with strong delivery guarantees.

Pattern 4: Query the source directly. If order service needs customer balance, it can call customer service synchronously and trust the response. This gives strong consistency for reads, but if customer service is down, order service can’t function. This is the tradeoff-you get consistency but lose availability.

In practice, we should design for eventual consistency by default. Most scenarios don’t need strong consistency, and the performance and availability benefits are huge. When we do need strong consistency, we can use synchronous calls with appropriate fallbacks. If customer service is down, we can queue the order and process it when customer service recovers.

The production gotcha is user experience. If your UI shows data that’s eventually consistent, users might see stale data and get confused. I always design UIs to handle this gracefully. Show “updating…” indicators, use optimistic updates, or explain that data might be slightly delayed. Don’t pretend everything is real-time when it isn’t.

📚 Related: Learn about event sourcing patterns in Event Sourcing Explained and how to ensure data consistency between microservices using the Outbox Pattern in The Outbox Pattern: Ensuring Data Consistency in Microservices.

9. What is the role of an API Gateway in a microservices architecture, and how have you used it in production?

API Gateways are one of those patterns that everyone implements differently. Some teams use them for everything, others avoid them entirely. The right answer depends on context, which is what interviewers are really probing for.

What They’re Really Asking:

Do you understand the single entry point pattern? Have you built systems with and without gateways? Can you explain the tradeoffs?

The Answer:

An API Gateway is a single entry point for all client requests. Instead of clients calling multiple services directly, they call the gateway, which routes requests to the appropriate services. The gateway handles cross-cutting concerns like authentication, rate limiting, routing, and response aggregation.

We can use API Gateways for external-facing APIs. When external clients need to access our system, they shouldn’t know about our internal service topology. The gateway provides a stable interface while we refactor services behind it. We can add, remove, or split services without breaking clients.

The gateway also centralizes authentication and authorization. Instead of implementing OAuth in every service, I do it once in the gateway. Services receive requests with user context already validated. This reduces code duplication and ensures consistent security policies.

Rate limiting is another common use case. I can throttle abusive clients at the gateway before they hit my services. This protects my infrastructure from traffic spikes or attacks. Without a gateway, I’d need to implement rate limiting in every service, which is inefficient and inconsistent.

Response aggregation is useful when clients need data from multiple services. Instead of making multiple round trips, the gateway can call multiple services and combine the responses. This reduces latency and simplifies client code. The tradeoff is tight coupling-if one service is slow, the entire aggregated response is slow.

In production, I’ve used both API Gateway-as-a-Service offerings like AWS API Gateway and self-hosted solutions like Kong or Zuul. The managed services are simpler but less flexible. Self-hosted gives me more control but requires more operational overhead.

The production gotcha is the gateway becoming a bottleneck. If all traffic flows through a single gateway, its failure brings down everything. I always run multiple gateway instances behind a load balancer. I also monitor gateway performance closely-if it becomes slow, everything becomes slow.

Some teams avoid gateways entirely and let clients call services directly. This works if you have few clients or if clients are internal and can handle service discovery. But for external APIs with many clients, a gateway is essential. The complexity tradeoff is worth it for the operational benefits.

10. Describe a time when you had to debug a production issue in a microservices environment. What was your approach?

This is the most revealing question. Anyone can explain theory, but debugging production issues in distributed systems requires real experience. The answer reveals whether you’ve actually built and operated microservices at scale.

What They’re Really Asking:

Have you been on-call at 2 AM debugging a distributed system? Can you systematically debug issues across multiple services? Do you understand the tools and techniques?

The Answer:

Here’s a systematic framework for debugging production issues:

1. Understand Scope (Metrics First):

Check dashboards for error rates, latency percentiles, and affected services. Identify if the issue is isolated or widespread, and correlate with recent deployments or traffic spikes.

2. Trace Request Flow (Correlation IDs & Tracing):

Extract correlation IDs from failed requests and trace the path across services. Distributed tracing shows where requests fail or slow down, identifying bottlenecks.

3. Analyze Logs:

Pull logs using correlation IDs for detailed errors and stack traces. Search for error patterns, connection failures, timeouts, and compare logs across services.

4. Check Infrastructure:

Verify service registry and health checks-services might be marked healthy but failing. Check resource utilization (CPU, memory, connection pools) and network connectivity.

5. Narrow Down & Fix:

Review code paths for resource leaks, missing error handling, or logic errors. Deploy fix with monitoring enabled, verify metrics return to baseline, and document the incident.

Common Strategies:

Start broad, narrow down (metrics → logs → traces → code review). Compare before/after deployments. Check dependencies (downstream services, databases, message brokers). Review recent changes and correlate timing.

Production Gotchas:

Health checks that don’t verify actual functionality can mask issues. Without correlation IDs and distributed tracing, debugging becomes guesswork. Good observability is essential-metrics show what’s wrong, logs show why, traces show where.

Conclusion

These ten questions reveal production experience-understanding not just what these patterns are, but when to use them and what can go wrong.

For a comprehensive collection of microservice interview questions with detailed answers and code examples, check out our Microservices Interview Questions page.

Originally published at https://codewiz.info.

I’ve learned more from watching conference talks on YouTube than from most online courses. There’s something about watching a framework maintainer explain why they made certain design decisions, or hearing a Netflix engineer describe how they handle 200 million users, that just doesn’t translate to written tutorials.

The problem? There are hundreds of conference channels out there, and most of them aren’t worth your time if you’re focused on Java and the JVM ecosystem. I’ve curated the five channels I keep coming back to-the ones where I actually finish the videos and walk away having learned something.

You can also read the same blog on my website here

1. Devoxx (@DevoxxForever)

👥 Subscribers: 169K | 📺 Videos: 4,302 | 👀 Total Views: 20.1M

Channel URL: https://www.youtube.com/@DevoxxForever

🎯 Why I recommend it: If you want one conference channel for Java, make it this one.

Devoxx Belgium is basically the JavaOne successor that we all needed. You’ll find talks from Brian Goetz explaining Project Valhalla, Venkat Subramaniam doing live coding sessions, and deep dives into JVM internals from the engineers who actually work on HotSpot. The production quality is solid, and they’re fast about uploading-usually within weeks of the conference.

One thing I appreciate: not only they have short informative sessions to get an idea about the new features, but they also have longer deep-dive sessions where engineers talk about specific problems they’ve solved. That’s where the real learning happens.

2. Spring I/O (@SpringIOConference)

👥 Subscribers: 47.4K | 📺 Videos: 393 | 👀 Total Views: 2.9M

Channel URL: https://www.youtube.com/@SpringIOConference

🎯 Why I recommend it: Straight from the Spring team-no middleman.

If you’re building anything with Spring Boot (and let’s be honest, most of us are), this channel is essential. These conferences bring in the actual Spring maintainers like Josh Long, Jürgen Höller, the Spring Security team, and they don’t just demo features. They explain the why behind design decisions.

I particularly like their Spring Security talks. The official docs are good, but watching someone walk through OAuth2 flows while explaining what can go wrong? That’s saved me hours of debugging.

3. GOTO Conferences (@GOTO-)

👥 Subscribers: 1.06M | 📺 Videos: 3,409 | 👀 Total Views: 73.1M

Channel URL: https://www.youtube.com/@GOTO-

🎯 Why I recommend it: Architecture and design talks that make you rethink how you build systems.

GOTO isn’t Java-specific, but that’s actually a strength. You’ll find Martin Fowler discussing refactoring, Sam Newman on microservices, and architects from companies like Spotify and Netflix explaining their systems. The Java content is excellent when it appears, but even the language-agnostic talks on architecture and distributed systems are directly applicable.

Fair warning: some talks are more “inspirational keynote” than “technical deep dive.” I tend to skip those. Filter by speaker or topic rather than watching everything.

4. InfoQ (@InfoQ)

👥 Subscribers: 233K | 📺 Videos: 1,781 | 👀 Total Views: 28.0M

Channel URL: https://www.youtube.com/@InfoQ

🎯 Why I recommend it: QCon talks plus interviews with people shaping the industry.

InfoQ curates content from QCon conferences worldwide, and they’ve got a good nose for what’s actually important versus what’s just hype. Their Java coverage includes interviews with OpenJDK contributors, JCP discussions, and practical talks on topics like observability and performance tuning.

What sets InfoQ apart is their podcast-style interviews. Sometimes you learn more from a 20-minute conversation with a framework author than from an hour-long conference talk. Their recent series on AI in software development has been surprisingly practical-not just “look at this cool demo” but “here’s what actually works in production.”

5. AWS Events (@AWSEventsChannel)

👥 Subscribers: 167K | 📺 Videos: 12,604 | 👀 Total Views: 68.9M

Channel URL: https://www.youtube.com/@AWSEventsChannel

🎯 Why I recommend it: If you’re deploying Java to AWS, this is required viewing.

Look, I know-it’s a vendor channel. But re:Invent sessions on Lambda cold starts with Java, Corretto performance tuning, and EKS deployment patterns are genuinely useful. They bring in customers who run serious Java workloads and have them explain what worked (and what didn’t).

The trick with AWS Events is knowing what to skip. Ignore the product announcements and marketing sessions. Search specifically for “Java,” “Spring Boot,” or “JVM” and you’ll find the sessions worth watching. Their talks on reducing Lambda cold start times for Java changed how I architect serverless applications.

The Bottom Line

You don’t need to watch everything. Pick one or two channels, find speakers whose style works for you, and make conference talks part of your regular learning routine. I usually watch one during lunch a few times a week-it adds up.

For more conference channels covering other languages and technologies, check out Developer Conference Channels on YTubeInfluencers.

Originally published at https://codewiz.info.

Java 25 released on September 16th, 2025 brings several significant features to the Java platform, including the finalization of Scoped Values, the introduction of Stable Values, and further refinements to Structured Concurrency. Let’s explore the key features included in the Java 25 release.

1.1 Stable Values (Preview)

Stable Values are variables that can be set only once during an application’s lifetime and stay unchanged after that. They provide a standardized way to lazily initialize constants, letting the JVM optimize them just like it does with final values.

This feature solves the long-standing problem of safe lazy initialization in Java. It offers better performance than final fields (which must be initialized at creation) and better safety than double-checked locking or other lazy initialization patterns.

You can learn more about Stable Values from this Stable Values Guide.

Example:

public class EmailService {
    private static final StableValue<SMTPClient> smtpClient = StableValue.of();
    
    public static void sendEmail(String to, String subject, String body) {
        SMTPClient client = smtpClient.orElseSet(() -> 
            new SMTPClient(loadConfiguration()));
        client.send(to, subject, body);
    }
}

1.2 Primitive Types in Pattern Matching (Third Preview)

This feature extends pattern matching to work with primitive types in both instanceof and switch expressions. This enhancement simplifies code that needs to match primitive types, reducing boilerplate and improving readability.

Example:

public void processValue(Object obj) {
    switch (obj) {
        case int i -> System.out.println("Integer: " + i);
        case long l -> System.out.println("Long: " + l);
        case String s -> System.out.println("String: " + s);
        default -> System.out.println("Unknown: " + obj);
    }
}

Related: Pattern Matching in Java — Deep dive into pattern matching, sealed types, destructuring, and related features leading up to Java 25.

1.3 Module Import Declarations (Final)

Module Import Declarations allow developers to import all the packages exported by a module with a single declaration. This simplifies working with modular libraries by significantly reducing import statement verbosity.

Example:

import module java.base;

void main() throws IOException {
    var names = List.of("Alice", "Bob", "Charlie");
    Path filePath = Paths.get("test.txt");
    Files.write(filePath, names);
}

1.4 Compact Source Files and Instance Main Methods (Final)

This feature simplifies Java program structure for beginners by eliminating the need for explicit class declarations and static main methods in simple programs. It lowers the barrier to entry for learning Java by allowing students to write their first programs without needing to understand large amounts of boilerplate code.

Example:

void main() {
    System.out.println("Hello, World!");
}

1.5 Flexible Constructor Bodies (Final)

Flexible Constructor Bodies allow statements to appear before an explicit constructor invocation (super(...) or this(...)). This enables cleaner initialization logic and reduces the need for repetitive code in constructors, giving developers more freedom in how they structure their object initialization.

Example:

public UserProfile(String rawUsername, String rawEmail) {
    // Sanitize input before calling superclass constructor
    var sanitizedUsername = sanitize(rawUsername);
    var sanitizedEmail = sanitize(rawEmail);
    
    super(sanitizedUsername, sanitizedEmail);
}

2. Performance and Runtime Improvements

2.1 Compact Object Headers (Final)

This feature reduces the size of object headers in the HotSpot JVM from between 96 and 128 bits down to 64 bits on 64-bit architectures. By reducing the per-object overhead, this change reduces heap size, improves deployment density, and increases data locality.

2.2 Generational Shenandoah

Generational Shenandoah introduces a generational mode for the Shenandoah garbage collector. This improves performance for applications with high allocation rates by separating young and old objects, allowing for more frequent collection of short-lived objects without scanning the entire heap.

3. Library Enhancements

3.1 Scoped Values (Final)

Scoped Values, now a finalized feature in Java 25, provide a safer and more structured way of sharing data within a thread and its child threads. They serve as a modern alternative to ThreadLocal.

Scoped values address the limitations of ThreadLocal (unconstrained mutability, unbounded lifetime) by providing a immutable, bounded-lifetime data sharing mechanism. It is particularly important for Virtual Threads where ThreadLocal can be expensive.

You can learn more about Scoped Values from this Scoped Values Guide.

Example:

public class UserContextDemo {
    public static final ScopedValue<String> userScopedVal = ScopedValue.newInstance();
    public static void main(String[] args) {
        ScopedValue.where(userScopedVal, "Alice").run(() -> {
            processUserRequest();
        });
    }
    
    static void processUserRequest() {
        System.out.println("Processing for user: " + userScopedVal.get());
    }
}

3.2 Structured Concurrency (Fifth Preview)

Structured Concurrency is an API that treats groups of related tasks running in different threads as a single unit of work. This simplifies concurrent programming by eliminating common risks like thread leaks and cancellation delays, while improving reliability and observability of concurrent code.

You can learn more about Structured Concurrency from this Structured Concurrency Guide.

Example:

public void generateReport(String stockSymbol) throws InterruptedException {
    try (var scope = StructuredTaskScope.open()) {
        var stockTask = scope.fork(() -> stockRepository.getStockHolding(stockSymbol));
        var marketPriceTask = scope.fork(() -> stockAPIClient.getStockPrice(stockSymbol));
        
        scope.join();
        
        // Process results
        printReport(stockTask.get(), marketPriceTask.get());
    }
}

3.3 Vector API (Tenth Incubator)

The Vector API allows developers to express vector computations that reliably compile to optimal vector hardware instructions. This dramatically improves performance for computationally intensive applications by leveraging SIMD (Single Instruction, Multiple Data) hardware capabilities.

3.4 Key Derivation Function API (Final)

The Key Derivation Function API provides a standard API for Key Derivation Functions (KDFs). This addition provides standardized, secure methods for deriving cryptographic keys, making it easier to implement secure key management in Java applications.

4. Security Enhancements

4.1 PEM Encodings of Cryptographic Objects (Preview)

This preview feature introduces a standard API for encoding and decoding cryptographic keys and certificates in the PEM format. This simplifies the handling of cryptographic artifacts, which are commonly exchanged in PEM format across different systems.

5. Tooling and Observability Updates

5.1 JFR CPU-Time Profiling (Experimental)

This experimental feature enhances JDK Flight Recorder (JFR) to capture more accurate CPU-time profiling information on Linux. It provides deeper insights into application performance by accurately measuring CPU consumption of individual methods, helping developers identify optimization targets more effectively.

5.2 JFR Method Timing & Tracing

This update extends JFR with facilities for method timing and tracing via bytecode instrumentation. It allows recording complete and exact statistics for specific methods without source code modifications, moving beyond sample-based statistics for critical code paths.

5.3 JFR Cooperative Sampling

JFR Cooperative Sampling improves the stability of JFR when asynchronously sampling Java thread stacks by walking call stacks only at safepoints while minimizing safepoint bias. This enhances the reliability of profiling in production environments by preventing crashes that could occur with previous asynchronous sampling techniques.

5.4 Ahead-of-Time Command-Line Ergonomics

This feature simplifies the process of creating ahead-of-time (AOT) caches by streamlining the command-line options. It makes it easier for developers to adopt AOT compilation for faster startup times without dealing with complex multi-step processes.

5.5 Ahead-of-Time Method Profiling

Ahead-of-Time Method Profiling improves warmup time by making method-execution profiles from a previous run available immediately upon startup. This enables the JIT compiler to generate native code immediately, significantly reducing the warmup period for Java applications.

Conclusion

JDK 25 continues the trend of modernizing Java with features that improve developer productivity, performance, and security. The finalization of Scoped Values and the introduction of Stable Values are particularly exciting for building robust, high-performance applications.

To stay updated with the latest updates in Java and Spring, follow us on LinkedIn and Medium.

Originally published at https://codewiz.info.

Spring Framework 7 and Spring Boot 4 introduced several new features and improvements. Let us explore some of the key features which are important for Java developers. Java 17 is still the baseline, but it’s recommended to use the latest LTS JDK (for example, Java 25) for better performance and security.

API Versioning

API versioning is the process of assigning unique version numbers to your API. As you introduce new features or make breaking changes, you can release a new version of your API while allowing existing clients to continue using the older version. This ensures that you don’t disrupt services for your users.

In earlier versions of Spring Boot, there was no built-in, opinionated way to handle API versioning. Developers had to implement versioning manually using Spring’s flexible request mapping capabilities.

With the introduction of Spring Framework 7, API versioning has been significantly streamlined through native support. The framework now provides an ApiVersionStrategy that centralizes the configuration and management of API versions. This eliminates the need for manual version resolution logic and reduces code duplication.

Configuration

You can configure API versioning by implementing WebMvcConfigurer and overriding the configureApiVersioning method:

@Configuration
public class WebConfiguration implements WebMvcConfigurer {
@Override
    public void configureApiVersioning(ApiVersionConfigurer configurer) {
        configurer.useRequestHeader("API-Version");
    }
}

This configuration tells Spring to extract the API version from the “API-Version” request header. You can configure other strategies as well: use configurer.useQueryParam("version") for query parameter-based versioning, configurer.usePathSegment() for path segment versioning, or configurer.useMediaTypeParameter() for media type-based versioning.

For Spring Boot applications, you can configure this using properties in application.properties:

spring.mvc.apiversion.use.header=API-Version

Using the Version Attribute

Once configured, you can specify the API version directly in your controller mappings using the new version attribute:

@RestController
public class ProductController {
@GetMapping(path = "/products/{id}", version = "1")
    public Product getProductV1(@PathVariable String id) {
        return productService.getProduct(id);
    }
    @GetMapping(path = "/products/{id}", version = "2")
    public ProductV2 getProductV2(@PathVariable String id) {
        return productService.getProductV2(id);
    }
}

Want more details?
See A Developer’s Guide to API Versioning in Spring Boot for in-depth strategies, legacy methods, and side-by-side code examples on API versioning in Spring Boot and Framework 7.

Resilience features

Till now for resilience features, we had to use Spring Retry and Resilience4j. With Spring Framework 7, we have got a native support for retry and concurrency limit features. For others like circuit breaker, rate limiting, etc., we still need to use Resilience4j.

@EnableResilientMethods
@Service
class PaymentService {
  @Retryable(maxAttempts = 4, delay = 100, multiplier = 2, maxDelay = 1000)
  @ConcurrencyLimit(3)
  public String charge(String id) { return "ok"; }
}

First we need to enable the resilience features in our application by adding the @EnableResilientMethods annotation. Then we can annotate our methods with @Retryable and @ConcurrencyLimit annotations.

Recommended Reading
For detailed examples of implementing retry and backoff using Spring Framework 7, see Implementing the Retry Pattern in Spring Boot.
For an introduction to circuit breaker, bulkhead and other resilience patterns, check out Resilient Microservices: Patterns & Diagrams.

JMS Client

Similar to JdbcClient and RestClient, we now have JmsClient to make JMS calls as an alternative to JmsTemplate.

public class MyJmsClient {
  private final JmsClient jmsClient;
  public MyJmsClient(JmsClient jmsClient) {
    this.jmsClient = jmsClient;
  }
  public void sendMessage(String message) {
    jmsClient.destination("queue1").send(message);
  }
  public String receiveMessage() {
    return jmsClient.destination("queue2").receive();
  }
}

HTTP Service Client Enhancements

Spring Framework 7 introduces the HTTP Service Registry to simplify managing multiple HTTP service clients. Instead of configuring each client individually, you can organize related services into groups and configure them collectively.

Define your HTTP service interface:

public interface InventoryService {
    @GetExchange("http://product-service/products/{id}")
    Product getProduct(@PathVariable String id);
    @PostExchange("http://product-service/products")
    ProductResponse createProduct(@RequestBody ProductRequest request);
}

Group and configure the service:

@ImportHttpServices(group = "inventory", types = {InventoryService.class})
@Configuration
public class InventoryClientConfig {
}

This approach centralizes configuration, reduces boilerplate, and makes it easier to manage shared settings like base URLs and authentication headers across related services.

After this, you can inject the service into your controller:

@RestController
public class InventoryController {
    private final InventoryService inventoryService;
    public InventoryController(InventoryService inventoryService) {
        this.inventoryService = inventoryService;
    }
    @GetMapping("/products/{id}")
    public Product getProduct(@PathVariable String id) {
        return inventoryService.getProduct(id);
    }
}

Null safety through JSpecify

Spring Framework 7 adopts JSpecify annotations to enhance null-safety by explicitly declaring the nullability of APIs, fields, and type usages. This helps prevent NullPointerException through build-time checks and makes the potential absence of values explicit in your code.

import org.jspecify.annotations.Nullable;
import org.jspecify.annotations.NonNull;

public class UserService {
    
    @NonNull
    public String getUserName(@NonNull String userId) {
        // userId is guaranteed to be non-null
        return userRepository.findById(userId).getName();
    }
    
    @Nullable
    public String findOptionalEmail(String userId) {
        // Return value may be null
        return userRepository.findEmailById(userId);
    }
}

JSpecify annotations work with tools like NullAway and are supported by IDEs such as IntelliJ IDEA and Eclipse. For Kotlin developers, these annotations are automatically translated to Kotlin’s native null-safety features, ensuring seamless integration.

Programmatic bean registration

Traditionally, registering multiple beans or handling complex registration logic in a @Configuration class was discouraged: each @Bean method should register only one bean, and its return type should be as concrete as possible. These guidelines, while ensuring clarity, have sometimes limited flexibility—especially when advanced conditional or bulk registration is needed.

Spring Framework 7 now includes a new programmatic bean registration feature via the BeanRegistrar contract, empowering developers to implement more sophisticated and dynamic registration logic with ease.

RestTestClient

Spring Framework 7 introduces RestTestClient, a testing utility for client-side REST API testing. It provides a fluent API for sending HTTP requests and verifying responses, with built-in assertions and integration with AssertJ for flexible response validation.

import org.springframework.test.web.client.RestTestClient;

@SpringBootTest
class UserControllerTest {
    
    @Autowired
    private WebApplicationContext context;
    
    @Test
    void shouldGetUser() {
        RestTestClient client = RestTestClient.bindToApplicationContext(context).build();
        
        client.get()
            .uri("/users/123")
            .exchange()
            .expectStatus().isOk()
            .expectBody(User.class)
            .value(user -> assertThat(user.getName()).isEqualTo("John"));
    }
}

RestTestClient simplifies testing by allowing developers to focus on request and response handling without needing an actual server, making it ideal for integration testing of REST endpoints.

Support for Jackson 3

Spring Framework 7 introduces support for Jackson 3, the latest major release of the JSON library.

Jackson 3 is designed to coexist with Jackson 2, allowing for a gradual migration path. Spring Boot 4 uses Jackson 3 as the default, while Spring Framework 7 maintains compatibility with both versions.

References

• Spring 7 release notes: Spring Framework 7.0 Release Notes

To stay updated with the latest updates in Java and Spring follow us on linked in and medium.

Originally published at https://codewiz.info.

CompletableFuture has been part of the Java toolbox since Java 8 and provides a powerful API for asynchronous programming on the JVM. It lets you compose asynchronous pipelines, control threading, and coordinate multiple tasks without directly dealing with low-level concurrency APIs. In this blog post, we will cover the core API features and then see how it fits alongside virtual threads and structured concurrency in modern Java.

What is CompletableFuture?

CompletableFuture is a class in the java.util.concurrent package which implements the Future and CompletionStage interfaces. It provides a rich API for asynchronous programming on the JVM. You can think of it as a container for a future result of an asynchronous operation.

Creating Futures

1.runAsync

runAsync is used to create a CompletableFuture that does not return a value.

CompletableFuture<Void> fireAndForget = CompletableFuture.runAsync(() -> {
    auditService.log("event");
});

2.supplyAsync

supplyAsync is used to create a CompletableFuture that returns a value. It takes a Supplier<T> as input which returns the result of the task. It returns a CompletableFuture<T> where T is the type of the value returned by the Supplier.

To get the result of the CompletableFuture, we can call the get method on it, but this will block the current thread until the result is available.

CompletableFuture<String> fetchData = CompletableFuture.supplyAsync(() -> {
    return httpClient.fetch("https://api.example.com/data");
});
String data = fetchData.get(); // Blocking call
System.out.println(data);

Both runAsync and supplyAsync methods use the common ForkJoinPool by default. Pass a custom executor when you need different sizing.

ExecutorService executor = Executors.newFixedThreadPool(10);

CompletableFuture<OrderDetails> orderFuture =
        CompletableFuture.supplyAsync(() -> orderClient.fetch(orderId), executor);

3.completedFuture

completedFuture is useful when you already have a value and want to seed a pipeline without scheduling work. It surfaces in testing and in branching flows where one side has a constant result.

CompletableFuture<Customer> cachedCustomer =
        CompletableFuture.completedFuture(customerCache.get(customerId));

Creating Pipelines

Below are some commonly used methods for chaining mutliple CompletableFuture objects to create a pipeline.

• thenApply: transform the result synchronously. This method is used when we want to apply some transformation on the result of the task.
• thenApplyAsync: transform the result asynchronously. This method is used when we want to apply some transformation on the result of the task asynchronously.
• thenCompose: flatten nested futures (think async flatMap). This method is used when we want to chain multiple CompletableFuture and one task depends on the result of the previous task.
• thenAccept / thenRun: consume results without returning a value.

CompletableFuture<BigDecimal> priceFuture = orderFuture
        .thenApply(OrderDetails::price) // Transform the result synchronously
        .thenCompose(price -> exchangeClient.convert(price, "USD")) // Chain multiple `CompletableFuture`s and one task depends on the result of the previous task
        .thenApply(converted -> converted.multiply(new BigDecimal("0.85"))) // Transform the result synchronously

Use thenCompose whenever the chained method produces a CompletableFuture. In the above example, we are calling exchangeClient.convert(price, "USD") which returns a CompletableFuture<BigDecimal>. So we are using thenCompose to chain the CompletableFuture objects.

Use thenApply when the chained method does not produce a CompletableFuture. In the above example, we are calling OrderDetails::price which returns a BigDecimal. So we are using thenApply to chain the CompletableFuture objects.

Combining Multiple Tasks

Below are some commonly used methods for combining multiple CompletableFuture objects.

• allOf: wait for all futures to complete.
• anyOf: resolve when the first completes.
• thenCombine: combine two futures’ results.

CompletableFuture<User> userFuture = userClient.fetch(userId);
CompletableFuture<List<Order>> ordersFuture = orderClient.fetchOrders(userId);

CompletableFuture<UserOrders> combined = userFuture.thenCombine(ordersFuture,
        (user, orders) -> new UserOrders(user, orders));
CompletableFuture<Void> allDone = CompletableFuture.allOf(userFuture, ordersFuture, auditFuture);

Collecting results from allOf requires unpacking the individual futures:

CompletableFuture<List<ProductPrice>> pricesFuture = CompletableFuture
        .allOf(priceFutures.toArray(CompletableFuture[]::new))
        .thenApply(v -> priceFutures.stream()
                .map(CompletableFuture::join)
                .toList());

anyOf finishes when the first future wins. Its result is typed as Object, so cast as needed.

CompletableFuture<Object> fastest =
        CompletableFuture.anyOf(searchFromCache(q), searchFromDb(q), searchFromApi(q));
String winningResult = (String) fastest.join();

join() retrieves the completed result without forcing you to catch checked exceptions; it mirrors get() but wraps failures in an unchecked CompletionException.

Exception Handling Strategies

Below are some commonly used methods for handling exceptions in CompletableFuture.

• exceptionally: recover with a fallback value.
• handle: inspect both success and failure.

CompletableFuture<String> profileFuture = profileClient.fetch(userId)
        .exceptionally(ex -> {
            metrics.increment("profile.fallback");
            return "{}"; // degraded response
        });

CompletableFuture<Order> safeOrderFuture = orderClient.fetch(orderId)
        .handle((result, ex) -> {
            if (ex != null) {
                log.error("Failed to fetch order {}", orderId, ex);
                throw new OrderUnavailableException(orderId, ex);
            }
            return result;
        });

Timeouts

We can use orTimeout to set a timeout on the CompletableFuture and if task doesn't complete within the timeout, it will throw a TimeoutException.

If you don’t want to throw an exception, you can use completeOnTimeout to set a default value if the task doesn't complete within the timeout.

CompletableFuture<Product> productFuture = productClient.fetchAsync(productId)
        .orTimeout(500, TimeUnit.MILLISECONDS)
        .exceptionally(ex -> {
            throw new ProductTimeoutException(productId, ex);
        });

CompletableFuture<Product> defaulted = productClient.fetchAsync(productId)
        .completeOnTimeout(Product.defaultProduct(), 300, TimeUnit.MILLISECONDS);

Virtual Threads with CompletableFuture

Java 21 introduced virtual threads, allowing use to run millions of threads in a normal commodity machine. CompletableFuture works seamlessly with virtual threads:

We just need to use Executors.newVirtualThreadPerTaskExecutor() to create a virtual thread executor and pass it to the supplyAsync method.

try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    CompletableFuture<String> salesReport = CompletableFuture.supplyAsync(() -> reportService.generate("sales"), executor);
    CompletableFuture<String> inventoryReport = CompletableFuture.supplyAsync(() -> reportService.generate("inventory"), executor);
    CompletableFuture<String> revenueReport = CompletableFuture.supplyAsync(() -> reportService.generate("revenue"), executor);
    CompletableFuture.allOf(salesReport, inventoryReport, revenueReport).join();
    List<String> reports = List.of(
            salesReport.get(),
            inventoryReport.get(),
            revenueReport.get());
}

Structured Concurrency — A Cleaner Way to Handle Concurrency

Structured concurrency, still a preview feature in Java 25 provides a better and cleaner way to handle concurrency. We can expect most of the use cases for which we use CompletableFuture to be replaced by StructuredTaskScope in the future.

Further Reading: Learn about the new Structured Concurrency API in Java 25 for a modern and safer approach to managing concurrency, cancellation, and result aggregation.

When to use Completable Future now

• Parallelising independent I/O-bound calls such as fetching data from multiple APIs.
• Orchestrating CPU-bound work where results feed into each other.
• Bridging callback-based APIs into a fluent, composable model.
• Implementing timeouts, retries, and fallbacks around asynchronous operations.

Conclusion

CompletableFuture is a powerful API for asynchronous programming on the JVM. It lets you compose asynchronous pipelines, control threading, and coordinate multiple tasks without dropping down to low-level concurrency APIs. It is a great tool to have in your toolbox when you need to write asynchronous code in Java.

To stay updated with the latest updates in Java and Spring, follow us on LinkedIn and Medium.

Originally published at https://codewiz.info.

Retry pattern is a resilience strategy that automatically re-attempts a failed operation (such as a network call) a specified number of times, often with delays in between attempts, to handle transient errors gracefully. Anyone who has worked with microservices of reasonable complexity knows that failures are inevitable. In a distributed system, where multiple services communicate over the network, failures can occur due to various reasons such as network issues, service downtime, or unexpected errors. These failures can lead to a poor user experience if not handled properly.

Many of these failures are transient in nature-they might be temporary network glitches, momentary service overloads, or brief connectivity issues that resolve themselves quickly. However, if these intermittent failures are not handled properly, they can lead to a cascading failure, where one service failure causes other dependent services to fail as well. This can result in a complete system outage, leading to significant downtime and loss of revenue.

There are multiple resilience patterns that can be used to handle such failures. In this blog post, we will explore the retry pattern in detail and implement it using Spring Boot.

📚 For a broader overview of resilience patterns (including retry, circuit breaker, bulkhead, and more), check out our complementary guide:
Top Resilience Patterns in Microservices and implementing in Spring Boot

Understanding the Retry Pattern

Before diving into the code, let’s understand how the retry pattern works:

The retry pattern involves automatically retrying a failed operation with the expectation that it might succeed on subsequent attempts. This is useful for handling transient failures such as network blips or temporary service unavailability.

In the above diagram, the client sends a request to Service A, which in turn calls Service B. If Service B fails, Service A will retry the call after a back off period. The back off period can be exponential, meaning it increases with each failure.

Implementing the Retry Pattern in a Spring Boot Application

Now that we understand the retry pattern, let’s see how to implement it in a Spring Boot application.

In this blog we will follow the new resilience features introduced in Spring Framework 7.0. For version prior to 7.0, you can refer to the previous blog where we implemented the retry pattern using Spring Retry.

As of Spring Framework 7.0, the @Retryable annotation is part of the core framework, so you no longer need to add the spring-retry dependency.

Enabling Resilient Methods

To enable the processing of resilience annotations, you can declare @EnableResilientMethods on a corresponding @Configuration class.

@Configuration
@EnableResilientMethods
public class AppConfig {
}

Let us say we have a method that fetches weather data from a weather API. We can annotate this method with @Retryable to enable retry functionality.

@Retryable(includes = IOException.class, maxAttempts = 3, delay = 100, jitter = 10,multiplier = 2)
public WeatherRecords.WeatherData getWeather(PlaceRecords.Location location, String travelDate){
    log.info("Getting weather data for location: {} and date: {}", location, travelDate);
    String uriString = UriComponentsBuilder.fromUriString("/forecast?lat=-{lat}&lon={long}&appid={apiKey}&units=metric")
            .buildAndExpand(location.latitude(), location.longitude(), apiKey)
            .toUriString();
    var weatherResponse = weatherClient.get()
            .uri(uriString)
            .retrieve()
            .body(WeatherRecords.WeatherResponse.class);
    return weatherResponse.list().stream()
            .filter(weatherData -> weatherData.dtTxt().startsWith(travelDate))
            .findFirst()
            .orElseThrow(()->new NoDataFoundException("No weather data found for the date",100));
}

In this code:

• The @Retryable annotation specifies that the method should be retried if it fails.
• includes specifies the exception types that should trigger a retry (in this case, IOException).
• maxAttempts specifies the maximum number of attempts (including the initial attempt), set to 3.
• delay specifies the initial delay in milliseconds before the first retry (100ms).
• multiplier specifies the multiplier for exponential backoff (2, so delays will be 100ms, 200ms, 400ms, etc.).
• jitter adds randomness to the delay to prevent thundering herd problems.

This configuration will retry the method up to 3 times when an IOException occurs, with exponential backoff starting at 100ms and doubling with each retry.

Programmatic Retry Support

RetryTemplate provides a programmatic API for retrying arbitrary blocks of code. We can use this to retry any code block that is not annotated with @Retryable.

var retryTemplate = new RetryTemplate();

retryTemplate.execute(
        () -> jmsClient.destination("notifications").send(...));

If you want to customize the retry logic, you can create a RetryPolicy and pass it to the RetryTemplate.

var retryTemplate = new RetryTemplate(RetryPolicy.withMaxAttempts(5));
retryTemplate.execute(
        () -> jmsClient.destination("notifications").send(...));

To stay updated with the latest updates in Java and Spring follow us on linked in and medium.

References

• Spring Framework Resilience Documentation

Originally published at https://codewiz.info.