DEV Community: closeup1202

I built a tool that shows you exactly which method slowed down after your last deploy published: false

closeup1202 — Tue, 14 Apr 2026 04:33:43 +0000

You deployed. p99 latency spiked. Now what?

Open Grafana. Check Jaeger. Dig through logs. Read the commit diff. Connect the dots yourself — every single time.

I got tired of that loop, so I built lofi: a zero-config library that links deploy events to method-level latency and lets you diff them from the terminal.

$ lofi diff a3f9c1..d82e04

Deploy Diff  a3f9c1 → d82e04
───────────────────────────────────────────────────────────────────
Method                          Before     After      Delta

───────────────────────────────────────────────────────────────────
OrderService.createOrder()      14.23ms  → 91.00ms   +76.77ms  ▲
PaymentClient.validate()        22.10ms  → 58.40ms   +36.30ms  ▲
UserService.findById()          3.05ms   → 3.12ms    +0.07ms   —
───────────────────────────────────────────────────────────────────
2 regression(s) detected

Regressed methods show in red. No dashboards required.

Two modes

deployment mode for teams not on Spring Boot.

	Actuator mode	Backend mode
Works with	Spring Boot	Any language with an OTel SDK (Java, Python, Node.js, Go, Ruby...)
Instrumentation	Spring AOP — no code changes	OpenTelemetry SDK or Java Agent
Setup	One dependency	`lofi-otelcol` + `lofi-backend`
Storage	`~/.lofi/metrics.db` (local SQLite)	`/data/metrics.db` (local SQLite)

The CLI auto-detects which mode the target is running — no extra flags needed.

How it works

(1) Actuator mode

lofi uses Spring AOP to automatically instrument every @Service, @Component, @Repository, @Controller, and @RestController bean in your application. No annotations on your business code. No agent. No code changes beyond adding the dependency.

When your app starts, it reads a GIT_COMMIT_HASH environment variable to know which deploy is running. Every method call gets timed (in nanoseconds) and flushed asynchronously to a local SQLite database at ~/.lofi/metrics.db. When you're ready to compare two deploys, you run lofi diff and it calls the actuator endpoint to compute the regression diff.

The library is careful about what it instruments:

Spring internals (org.springframework.*) → skipped
Jakarta Servlet filters and MVC interceptors → skipped (avoids Security filter chain conflicts)
AspectJ @aspect classes → skipped (avoids proxy-on-proxy chaos)
JDK dynamic proxies like Spring Data JPA repositories → skipped (their time is already captured through the enclosing service call)

(2) Backend mode

lofi-backend runs as a standalone server that receives span data from lofi-otelcol — a custom OpenTelemetry Collector binary. Your app sends traces via the standard OTLP protocol using any OTel SDK, and
lofi-otelcol extracts method duration and commit hash, then forwards them to lofi-backend.

Your App (any language) 
    │  OTLP (HTTP :4318 / gRPC :4317)
    ▼
lofi-otelcol
    │  POST /lofi/ingest 
    ▼  
lofi-backend (:9292) 
    │
    ▼  lofi-cli

# Start the full stack
docker compose up

# Java — via OTel Agent (no code changes)
OTEL_RESOURCE_ATTRIBUTES=deployment.commit.hash=$(git rev-parse --short HEAD) \
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 \ 
java -javaagent:opentelemetry-javaagent.jar -jar your-app.jar

# Python — via OTel SDK
GIT_COMMIT_HASH=py-v1 python main.py  # spans sent via OTLP to lofi-otelcol

# Compare deploys
lofi diff py-v1..py-v2 --url http://localhost:9292

The only requirement: name your spans as ClassName.methodName and set deployment.commit.hash as a resource attribute. lofi-otelcol handles everything else.

Getting started in 5 steps (Actuator mode)

1. Add the dependency

Gradle:

implementation 'io.github.closeup1202:lofi-spring-boot-starter:0.3.2'

Maven:

<dependency>
  <groupId>io.github.closeup1202</groupId>
  <artifactId>lofi-spring-boot-starter</artifactId>
  <version>0.3.2</version>
</dependency>

2. Expose actuator endpoints

  management:
    endpoints:
      web:
        exposure:
          include: lofi

3. Set the commit hash and run

export GIT_COMMIT_HASH=$(git rev-parse --short HEAD)
./gradlew bootRun
# [LO-FI] Monitoring active — commit: a3f9c1 | store: sqlite | regression-threshold: 0.2

4. Verify metrics via actuator

Send some traffic to your app, then check the raw JSON directly:

curl http://localhost:8080/actuator/lofi/a3f9c1

  {
    "commitHash": "a3f9c1",
    "deployedAt": "2024-11-01T09:00:00Z",
    "metrics": [
      {
        "className": "com.example.OrderService",
        "methodName": "createOrder",
        "elapsedMs": 14.23,
        "recordedAt": "2024-11-01T09:01:23Z"
      }
    ]
  }

Once you have two deploys' worth of data, you can also diff them directly:

curl "http://localhost:8080/actuator/lofi/diff?base=a3f9c1&head=d82e04"

5. Install the CLI for a better view

The CLI renders the same data as a formatted table with regression highlighting — easier to read at a glance than raw JSON.

Install the CLI

npm install -g @closeup1202/lofi-cli

Three commands:

lofi diff .. — compare latency between two deploys
lofi snapshot — inspect metrics for a single deploy
lofi check .. — CI gate: fail if regression exceeds threshold

lofi diff a3f9c1..d82e04 --url http://localhost:9090
lofi snapshot a3f9c2 --url http://localhost:9090
lofi check a3f9c1..d82e04 --threshold-ms 50 --url http://localhost:9090

No commit hash? No problem

Not sure which hash to compare? Run lofi diff or lofi snapshot without arguments —
the CLI fetches your recorded deploys and lets you pick with arrow keys.

$ lofi diff --url http://localhost:9090

? Select base commit (before): 
❯ a3f9c1  (4/14/2026, 1:10:00 PM, 6 metrics)
  d82e04  (4/13/2026, 9:22:00 AM, 12 metrics) 

? Select head commit (after):   
  a3f9c1  (4/14/2026, 1:10:00 PM, 6 metrics) 
❯ d82e04  (4/13/2026, 9:22:00 AM, 12 metrics)

Using lofi check in CI

lofi check exits with code 1 if any method exceeds the threshold — designed to fail a CI step automatically.

# GitHub Actions
- name: Check latency regression
  env:
    BASE: ${{ github.event.pull_request.base.sha }}
    HEAD: ${{ github.event.pull_request.head.sha }}
  run: lofi check $BASE..$HEAD --threshold-ms 50 --url https://staging.myapp.com

lofi check is a staging → production gate, not a pre-deploy check. Both commits need to be deployed with metrics collected before the comparison is meaningful. If no metrics are found for a commit, it
prints a warning and exits cleanly — so adding it to an existing pipeline won't break anything.

You can also output results as JSON or markdown:

# Parse results in CI
lofi check $BASE..$HEAD --threshold-ms 50 --format json | jq '.exceeded[].signature' 

# Post a report as a PR comment
lofi check $BASE..$HEAD --threshold-ms 50 --format markdown > report.md
gh pr comment $PR_NUMBER --body-file report.md

What it stores (and where)

All data stays local. lofi writes a SQLite file to ~/.lofi/metrics.db. No telemetry, no cloud, nothing leaves your machine unless you opt in to a dashboard (coming later).

If you're running in Docker or Kubernetes, mount a volume at /root/.lofi so the database survives container restarts:

docker run \ 
  -e GIT_COMMIT_HASH=$(git rev-parse --short HEAD) \
  -v $HOME/.lofi:/root/.lofi \
  my-app

Spring Security note

If your app uses Spring Security, the actuator endpoints return 403 by default. The cleanest fix is management port isolation — run actuator on a separate internal port that's never exposed publicly:

management:
  server:
    port: 9090

lofi diff a3f9c1..d82e04 --url http://localhost:9090

No security config changes needed.

Configuration

lofi:
  store-type: sqlite              # or in-memory (for tests/dev)
  regression-threshold: 0.2       # 20% increase = regression
  buffer:
    flush-threshold: 100
    flush-delay-ms: 5000
    queue-capacity: 1000

JSR-303 validation runs at startup — if you misconfigure a value, all violations are reported at once rather than stopping at the first one.

Current state and roadmap

lofi is in early development. It currently works best in single-pod environments (each pod has its own SQLite file). Multi-pod metric aggregation and a team dashboard are on the roadmap.

Requires Spring Boot 3.x and Java 17+.

GitHub: https://github.com/closeup1202/lofi
npm: https://www.npmjs.com/package/@closeup1202/lofi-cli
Maven Central: https://central.sonatype.com/artifact/io.github.closeup1202/lofi-spring-boot-starter

Feedback welcome — open an issue or drop a comment below.

Kafka Lag Is High — But Why? I Built a CLI to Answer That

closeup1202 — Tue, 07 Apr 2026 03:29:40 +0000

klag — A CLI That Tells You Why Your Kafka Consumer Is Lagging

You've seen it before: your Kafka consumer lag is climbing. You open Grafana, stare at the offset graphs, and start guessing.

Is the producer sending too much? Did a rebalance fire? Is the consumer process even alive?

klag is a CLI tool I built to skip the guessing. It connects to your Kafka broker, snapshots lag per partition, samples produce/consume rates, and runs a set of detectors to tell you the root cause — directly in your terminal.

Install

npm install -g @closeup1202/klag

Basic Usage

# One-shot analysis
klag -b localhost:9092 -g my-consumer-group

# Watch mode — refreshes every 5s
klag -b localhost:9092 -g my-consumer-group --watch

# Omit --group to pick interactively from a live list
klag -b localhost:9092

What It Detects

klag runs up to five detectors after collecting a lag snapshot and a rate sample:

Detector	What it catches
`PRODUCER_BURST`	Produce rate is 2x+ higher than consume rate — consumer can't keep up
`SLOW_CONSUMER`	Consumer has stalled — produce rate is active but consume rate is near zero
`OFFSET_NOT_MOVING`	Offsets haven't advanced despite active production — possible processing deadlock
`REBALANCING`	Group is in `PreparingRebalance` / `CompletingRebalance` — consumption paused
`HOT_PARTITION`	One partition holds a disproportionate share of total lag

Each result includes a description of what was observed and a suggestion for what to do next.

Sample Output

⚡ klag  v0.5.0

🔍 Consumer Group: my-consumer-group
   Broker:         localhost:9092
   Collected At:   2026-04-06 14:32:01 (Asia/Seoul)

   Group Status : 🚨 CRITICAL   Total Lag : 80,500   Drain : 58m15s

┌──────────────────┬───────────┬──────────────────┬────────────────┬────────┬────────────┬───────────┬──────────────┬──────────────┐
│ Topic            │ Partition │ Committed Offset │ Log-End Offset │ Lag    │ Status     │ Drain     │ Produce Rate │ Consume Rate │
├──────────────────┼───────────┼──────────────────┼────────────────┼────────┼────────────┼───────────┼──────────────┼──────────────┤
│ orders           │         0 │        1,200,000 │      1,242,000 │ 42,000 │ 🔴 HIGH    │ 58m20s    │ 120.0 msg/s  │  12.0 msg/s  │
│                  │         1 │        1,198,500 │      1,237,000 │ 38,500 │ 🔴 HIGH    │ 58m10s    │ 115.0 msg/s  │  11.0 msg/s  │
└──────────────────┴───────────┴──────────────────┴────────────────┴────────┴────────────┴───────────┴──────────────┴──────────────┘

🔎 Root Cause Analysis

   [PRODUCER_BURST] orders
   → produce rate 235.0 msg/s vs consume rate 23.0 msg/s (10.2x difference) — consumer is falling behind ingestion rate
   → Suggestion: Consider increasing consumer instances or partition count

SSL & SASL Support

For production clusters:

# SASL/SCRAM
klag -b broker:9092 -g my-group \
  --sasl-mechanism scram-sha-256 \
  --sasl-username user \
  --sasl-password pass   # or set KLAG_SASL_PASSWORD env var

# Mutual TLS
klag -b broker:9092 -g my-group \
  --ssl-ca ./ca.pem \
  --ssl-cert ./client.pem \
  --ssl-key ./client.key

.klagrc Config File

Tired of typing the same flags? Drop a .klagrc in your project root or home directory:

{
  "broker": "kafka.internal:9092",
  "group": "my-consumer-group",
  "interval": 5000,
  "timeout": 5000,
  "ssl": {
    "enabled": true,
    "caPath": "/etc/kafka/ca.pem", 
    "certPath": "/etc/kafka/client.crt",
    "keyPath": "/etc/kafka/client.key"
  },
  "sasl": {
    "mechanism": "plain",
    "username": "user"
  }
}

CLI flags always take precedence over the config file.

JSON Output

For integrations or scripting:

klag -b localhost:9092 -g my-group --json

Returns a full JSON payload with partition-level lag, rate snapshots, and RCA results.

How It Works

Lag collection — connects via KafkaJS, fetches committed offsets and log-end offsets for every partition in the group
Rate sampling — waits one interval (default 5s), collects offsets again, computes per-partition produce/consume rates
Analysis — runs the detector pipeline; each detector reads the same snapshot independently
Report — renders a colored table with severity levels (OK / WARN / HIGH) and drain time estimates

Severity is based on time-to-drain when rate data is available:

Level	Drain time at current consume rate
`OK`	Under 60 seconds
`WARN`	60s – 5 minutes
`HIGH`	Over 5 minutes, or consume rate is zero

The detectors are mutually exclusive by design — PRODUCER_BURST and SLOW_CONSUMER can't both fire for the same topic, which keeps the output clean.

What's Next

Alert mode — non-zero exit code when lag exceeds a threshold
Partition-level RCA breakdown
Prometheus metrics export

How I Reduced Kafka Boilerplate by 90% with Curve - A Declarative Event Library for Spring Boot

closeup1202 — Thu, 19 Feb 2026 04:11:05 +0000

I built Curve, an open-source Spring Boot library that turns 30+ lines of Kafka event publishing code into a single @PublishEvent annotation. It's production-ready with PII protection, Dead Letter Queue (DLQ), transactional outbox pattern, and AWS KMS integration.

The Problem: Too Much Boilerplate

In microservices, publishing events to Kafka is essential but repetitive. Here's what typical event publishing looks like:

  @Service
  public class UserService {
      @Autowired private KafkaTemplate<String, Object> kafka;
      @Autowired private ObjectMapper objectMapper;

      public User createUser(UserRequest request) {
          User user = userRepository.save(new User(request));

          try {
              // Manual event creation
              EventEnvelope event = EventEnvelope.builder()
                  .eventId(UUID.randomUUID().toString())
                  .eventType("USER_CREATED")
                  .occurredAt(Instant.now())
                  .publishedAt(Instant.now())
                  .metadata(/* extract actor, trace, source... */)
                  .payload(/* map to DTO... */)
                  .build();

              // Manual PII masking
              String json = maskPii(objectMapper.writeValueAsString(event));

              // Manual Kafka send with retry
              kafka.send("user-events", json)
                  .get(30, TimeUnit.SECONDS);

          } catch (Exception e) {
              log.error("Failed to publish event", e);
              sendToDlq(event);
          }

          return user;
      }
  }

30+ lines of boilerplate. And you need to repeat this for every event type.

The Solution: Just Add One Annotation

With Curve, the same logic becomes:

  @Service
  public class UserService {

      @PublishEvent(eventType = "USER_CREATED")
      public User createUser(UserRequest request) {
          return userRepository.save(new User(request));
      }
  }

That's it. Everything else is handled automatically:

✅ Event ID generation (Snowflake algorithm)
✅ Metadata extraction (actor, trace, source)
✅ PII masking/encryption
✅ Kafka publishing with retry
✅ DLQ on failure
✅ Metrics collection

Key Features That Make It Production-Ready

1. Automatic PII Protection

Sensitive data is automatically protected with @PiiField:

  public class UserEventPayload implements DomainEventPayload {
      @PiiField(type = PiiType.EMAIL, strategy = PiiStrategy.MASK)
      private String email;  // "user@example.com" → "user@***.com"

      @PiiField(type = PiiType.PHONE, strategy = PiiStrategy.ENCRYPT)
      private String phone;  // AES-256-GCM encrypted

      @PiiField(type = PiiType.ID_NO, strategy = PiiStrategy.HASH)
      private String id;    // HMAC-SHA256 hashed
  }

Supports AWS KMS and HashiCorp Vault for key management with envelope encryption.

2. 3-Tier Failure Recovery

Events never get lost, even when Kafka is completely down:

Main Topic → DLQ → Local File Backup → S3 Backup (optional)

3. Transactional Outbox Pattern

Guarantees atomicity between database transactions and event publishing:

  @PublishEvent(
      eventType = "ORDER_CREATED",
      outbox = true,
      aggregateType = "Order",
      aggregateId = "#result.orderId"
  )
  @Transactional
  public Order createOrder(OrderRequest req) {
      return orderRepo.save(new Order(req));
  }

Uses exponential backoff and SKIP LOCKED to prevent duplicate processing in multi-instance environments.

4. Built-in Observability

Health check and metrics out of the box:

  # Health check
  curl http://localhost:8080/actuator/health/curve
  {
    "status": "UP",
    "details": {
      "kafkaProducerInitialized": true,
      "clusterId": "lkc-abc123",
      "nodeCount": 3,
      "topic": "event.audit.v1",
      "dlqTopic": "event.audit.dlq.v1"
    }
  }

  # Custom metrics
  curl http://localhost:8080/actuator/curve-metrics
  {
    "summary": {
      "totalEventsPublished": 1523,
      "successRate": "99.80%"
    }
  }

Architecture: Hexagonal Design

Curve follows Hexagonal Architecture (Ports & Adapters) to keep the core domain framework-independent:

  curve/
  ├── core/                    # Pure domain (no Spring/Kafka)
  │   ├── envelope/            # EventEnvelope, Metadata
  │   ├── port/                # EventProducer interface
  │   └── validation/          # Domain validators
  │
  ├── spring/                  # Spring adapter
  │   ├── aop/                 # @PublishEvent aspect
  │   └── context/             # Context providers
  │
  ├── kafka/                   # Kafka adapter
  │   └── producer/            # KafkaEventProducer
  │
  ├── kms/                     # AWS KMS / Vault adapter
  └── spring-boot-autoconfigure # Auto-configuration

This makes it testable (no framework needed) and extensible (swap Kafka for RabbitMQ, etc.).

Performance

Benchmarked with JMH on AWS EC2 t3.medium (Kafka 3.8, 3-node cluster):

Sync mode: ~500 TPS
Async mode: ~10,000+ TPS
With MDC Context Propagation: Trace IDs preserved even in async threads

Quick Start

1. Add Dependency

  dependencies {
      implementation 'io.github.closeup1202:curve:0.1.2'
  }

2. Configure

  spring:
    kafka:
      bootstrap-servers: localhost:9092

  curve:
    enabled: true
    kafka:
      topic: event.audit.v1
      dlq-topic: event.audit.dlq.v1

3. Use

  @PublishEvent(eventType = "ORDER_CREATED", severity = EventSeverity.INFO)
  public Order createOrder(OrderRequest request) {
      return orderRepository.save(new Order(request));
  }

Done!

Lessons Learned

1. Hexagonal Architecture Was Worth It

Initially, I considered coupling directly to Spring. But isolating the core domain made:

Testing 10x easier (no Spring context needed)
Evolution safer (can change frameworks without breaking core logic)
Reusability possible (core can be used in non-Spring projects)

2. Security Defaults Matter

I started with simple StandardEvaluationContext for SpEL but switched to SimpleEvaluationContext to block dangerous operations (constructor calls, type references). Small change, huge security impact.

3. Documentation Is Critical for Adoption

I spent 30% of development time on docs:

30+ markdown files (Getting Started, Operations, Troubleshooting)
English + Korean versions
MkDocs Material for beautiful GitHub Pages

Result: Users can onboard in < 5 minutes.

4. Maven Central Publishing Is Hard

Getting published required:

GPG signing
Nexus Sonatype account
Proper POM metadata
Source/Javadoc JARs

But it's essential for credibility. No one trusts a library not on Maven Central.

Comparison with Alternatives

Feature	Spring Events	Spring Cloud Stream	Curve
Kafka Integration	❌	✅	✅
Declarative Usage	✅	△	✅
Standardized Schema	❌	❌	✅
PII Protection	❌	❌	✅
AWS KMS Integration	❌	❌	✅
DLQ + Local Backup	❌	△ ¹	✅
Transactional Outbox	❌	❌	✅
Health Check	❌	❌	✅
Boilerplate Code	Medium	High	Minimal

¹ Spring Cloud Stream supports Dead Letter Topics (broker-side),
but has no offline fallback for complete broker outages.
Curve adds Local File and S3 backup, so events survive even when
Kafka itself is unreachable.

What's Next?

Roadmap for v1.0.0 (Q3 2026):

GraphQL subscription support
AWS EventBridge adapter
Grafana dashboard template
gRPC event streaming
Multi-cloud KMS (GCP, Azure)

Try It Yourself

Clone the sample application
git clone https://github.com/closeup1202/curve.git
Start Kafka with Docker
docker-compose up -d
Run the app
cd curve/sample
../gradlew bootRun
Create an event

  curl -X POST http://localhost:8081/api/orders \
      -H "Content-Type: application/json" \
      -d '{
        "customerId": "cust-001",
        "customerName": "John Doe",
        "email": "john@example.com",
        "phone": "010-1234-5678",
        "productName": "MacBook Pro",
        "quantity": 1,
        "totalAmount": 3500000
      }'

Check Kafka UI

visit http://localhost:8080 in your browser

Contributing

Curve is MIT licensed and welcomes contributions! Whether it's:

🐛 Bug reports
💡 Feature requests
📖 Documentation improvements
🧪 Test coverage

Check out the Contributing Guide.

Final Thoughts

Building Curve taught me that good abstractions save time. Instead of writing the same Kafka code over and over, I invested time creating a reusable library.

If you're building event-driven microservices with Spring Boot and Kafka, give Curve a try. It might save you hundreds of lines of boilerplate.

✨ Star on GitHub: https://github.com/closeup1202/curve
📦 Maven Central: https://central.sonatype.com/artifact/io.github.closeup1202/curve
📖 Docs: https://closeup1202.github.io/curve/

What do you think? Have you built similar abstraction layers in your projects? I'd love to hear your experiences in the comments! 💬

8 Spring @Transactional Pitfalls That Break Production (And How to Catch Them All)

closeup1202 — Thu, 23 Oct 2025 13:59:48 +0000

We've all been there. You add @Transactional to a method, expecting it to magically handle database transactions. Then production hits, and suddenly transactions aren't working as expected. No errors, no warnings—just silent failures.

After analyzing thousands of Spring codebases and building an IDE plugin for transaction inspection, I've identified 8 critical anti-patterns that repeatedly break production systems. Each one is silent, each one compiles fine, and each one can destroy your data integrity.

Let me show you each one and—more importantly—how to catch them automatically before they reach production.

1. The Silent Killer: Same-Class Method Calls

This is the #1 cause of transaction failures, and it's completely silent.

@Service
public class UserService {

    @Transactional
    public void updateUser(Long id) {
        // This works fine
        User user = findById(id);
        user.setName("Updated");
    }

    @Transactional
    public User findById(Long id) {
        // ❌ This @Transactional is IGNORED!
        return userRepository.findById(id);
    }
}

Why it fails: Spring uses AOP proxies. When you call findById() from within the same class, you're calling the actual method—not the proxy. No proxy = no transaction.

The fix:

@Service
public class UserService {

    @Autowired
    private UserService self; // Inject self-reference

    @Transactional
    public void updateUser(Long id) {
        User user = self.findById(id); // ✅ Call through proxy
        user.setName("Updated");
    }
}

2. The Private Method Trap

@Service
public class OrderService {

    @Transactional  // ❌ This does NOTHING
    private void processOrder(Order order) {
        orderRepository.save(order);
    }
}

Why it fails: Spring AOP proxies can't intercept private methods. The annotation is simply ignored.

The fix: Make it public or protected.

3. The Final Method Problem

@Service
public class PaymentService {

    @Transactional  // ❌ Won't work with CGLIB proxies
    public final void processPayment(Payment payment) {
        paymentRepository.save(payment);
    }
}

Why it fails: CGLIB (Spring's default proxy mechanism) can't override final methods. The proxy subclasses your bean and overrides methods to add transactional behavior, but final methods can't be overridden—so the transaction is never applied.

🧠 Important caveat: If your bean implements an interface, Spring may use a JDK Dynamic Proxy instead of CGLIB. JDK proxies don't have this limitation because they work through the interface contract, not subclassing. So if PaymentService implements IPaymentService, the final method would still be called through the proxy—though it's still bad practice to use final on interface implementation methods.

4. The Checked Exception Surprise

This one is sneaky:

@Transactional
public void importUsers(File file) throws IOException {
    List<User> users = parseFile(file);  // throws IOException
    userRepository.saveAll(users);
}

What happens: If parseFile() throws IOException, the transaction DOESN'T rollback by default!

Why: Spring only rolls back on unchecked exceptions (RuntimeException). Checked exceptions don't trigger rollback.

The fix:

@Transactional(rollbackFor = IOException.class)
public void importUsers(File file) throws IOException {
    // Now it rolls back on IOException ✅
}

5. The @async + @Transactional Conflict

@Async
@Transactional  // ❌ These two don't play well together
public void sendEmailAsync(Long userId) {
    User user = userRepository.findById(userId);
    emailService.send(user.getEmail());
}

Why it fails: @Async runs in a different thread. The transaction context doesn't propagate to the async thread, causing LazyInitializationException or no transaction at all.

The fix: Separate concerns or use @TransactionalEventListener.

6. Writing in readOnly Transactions

@Transactional(readOnly = true)
public void updateUserStats(Long userId) {
    User user = userRepository.findById(userId);
    user.setLoginCount(user.getLoginCount() + 1);
    userRepository.save(user);  // ❌ Logical error!
}

What happens: readOnly = true is a hint to the persistence provider (like Hibernate). It doesn't prevent writes at the database level—it just tells Hibernate to skip dirty checking and flushing.

The unpredictable behavior:

Hibernate: May skip the flush, so updates silently don't get persisted. Your object changes, but the database doesn't.
Some JPA providers: Throw an exception when you try to call save() in a read-only transaction.
Others: Allow the write but don't flush changes to the database.

The real danger: Your code "works" locally because Hibernate usually flushes anyway, but in production with different configuration or database pooling, writes mysteriously disappear.

The fix: Don't use readOnly = true as an enforcement mechanism. Use it only for actual read operations:

@Transactional(readOnly = true)
public User getUserStats(Long userId) {
    return userRepository.findById(userId);  // ✅ Safe and clear
}

@Transactional  // Remove readOnly or use a separate method
public void updateUserStats(Long userId) {
    User user = userRepository.findById(userId);
    user.setLoginCount(user.getLoginCount() + 1);
    userRepository.save(user);
}

7. The N+1 Query Time Bomb

@Transactional
public void processOrders() {
    List<Order> orders = orderRepository.findAll();

    orders.forEach(order -> {
        // ❌ This triggers a separate query for EACH order
        Customer customer = order.getCustomer();  // LAZY by default
        System.out.println(customer.getName());
    });
}

What happens: If you have 100 orders, this runs 101 queries (1 for orders + 100 for customers). This includes not just @OneToMany and @ManyToMany, but also single-entity relationships like @ManyToOne(fetch = LAZY) and @OneToOne(fetch = LAZY).

The fix: Use @EntityGraph, JOIN FETCH, or batch loading strategies.

8. The Propagation Conflict Nightmare

This one hits you at runtime with cryptic exceptions:

@Service
public class PaymentService {

    @Autowired
    private TransferService transferService;

    @Transactional(propagation = Propagation.MANDATORY)
    public void transfer(Long from, Long to, BigDecimal amount) {
        transferService.executeTransfer(from, to, amount);
    }
}

@Service
public class TransferService {

    @Transactional  // ❌ Called without active transaction
    public void executeTransfer(Long from, Long to, BigDecimal amount) {
        accountRepository.debit(from, amount);
        accountRepository.credit(to, amount);
    }
}

Why it fails: propagation = MANDATORY means "this method MUST be called within an existing transaction." If called without one, Spring throws IllegalTransactionStateException. Similar disasters happen with:

NEVER - If you call a NEVER method from within a transaction, it explodes
REQUIRES_NEW - Creates independent transactions, risking data inconsistency

The fix: Ensure calling methods have appropriate @Transactional context, or adjust propagation mode to match the calling context.

The Problem: IDEs Don't Warn You

The biggest issue? Your IDE doesn't catch any of these mistakes. They all compile fine. Tests might even pass. Then production breaks.

After spending too many hours debugging these issues across different projects, I built an IntelliJ IDEA plugin that detects all 8 anti-patterns automatically—right in your editor, as you type.

Introducing: Spring Transaction Inspector

What it does:

✅ 8 comprehensive inspections for Spring transaction anti-patterns
✅ Real-time detection as you type in your editor
✅ Smart quick-fixes for each issue (auto-add rollbackFor, change visibility, etc.)
✅ Gutter icons with visual indicators for transaction boundaries
✅ Customizable settings - enable/disable any inspection individually
✅ Type-based detection - 95%+ accuracy using repository interface verification
✅ Multi-JPA support - Works with javax.persistence (JPA 2.x) and jakarta.persistence (JPA 3.0+)

Example in Action

When you write code with transaction issues:

@Transactional(propagation = Propagation.MANDATORY)
public void criticalOperation() {
    // ⚠️ Plugin warning: "Method requires an active transaction"
}

You get:

🔴 Clear warning highlighting
💡 Quick-fix suggestions
📋 Detailed explanation of the issue
✨ One-click fixes for most common issues

The 8 Inspections

#	Inspection	Severity	Quick Fix
1	Same-class @Transactional calls	⚠️ WARNING	Suppress only (requires refactoring)
2	Private/final/static methods	⚠️ WARNING	Change visibility, remove modifier
3	N+1 Query Detection	⚠️ WARNING	Informational (use Fetch-Join or @EntityGraph)
4	Write in read-only transaction	⚠️ WARNING	Remove readOnly=true
5	Checked exceptions	⚠️ WARNING	Add rollbackFor attribute
6	@async + @Transactional	🔴 ERROR	Remove conflicting annotation
7	Read-only calling write methods	⚠️ WARNING	Change to REQUIRES_NEW propagation
8	Propagation conflicts	🔴 ERROR	Add @Transactional to caller

Installation

Via JetBrains Marketplace (Easiest)

Open IntelliJ IDEA (Community or Ultimate)
Go to Settings → Plugins → Marketplace
Search for "Spring Transaction Inspector"
Click Install

Manual Installation

Install from JetBrains Marketplace

Configuration

After installation, go to Settings → Tools → Spring Transaction Inspector to:

Enable/disable individual inspections
Toggle N+1 detection in loops vs streams
Show/hide gutter icons
Customize inspection severity levels

Open Source & MIT Licensed

The plugin is completely open source and maintained on GitHub:

📦 GitHub Repository
🐛 Report Issues & Request Features
⭐ Star if you find it useful!

Real Impact

This plugin has caught transaction bugs before they reached production:

Prevented silent transaction failures
Caught lazy loading exceptions before they happen
Detected data consistency issues that would cost hours to debug
Identified propagation conflicts that would cause runtime exceptions

For Spring Boot Developers

If you're working with:

Spring Data JPA
Spring Boot 2.x / 3.x
Hibernate or JPA
Complex transaction logic

...then this plugin is essential. It essentially gives you a transaction expert reviewing every line of code as you type.

What transaction issues have you encountered in production? Drop a comment below—I might add them to the plugin!

If this saves you even one hour of debugging, it's worth the install. Try it today and protect your data integrity! 🚀

DEV Community: closeup1202

I built a tool that shows you exactly which method slowed down after your last deploy published: false

Two modes

How it works

(1) Actuator mode

(2) Backend mode

Getting started in 5 steps (Actuator mode)

1. Add the dependency

2. Expose actuator endpoints

3. Set the commit hash and run

4. Verify metrics via actuator

5. Install the CLI for a better view

Install the CLI

Three commands:

No commit hash? No problem

Using lofi check in CI

What it stores (and where)

Spring Security note

Configuration

Current state and roadmap

Kafka Lag Is High — But Why? I Built a CLI to Answer That

klag — A CLI That Tells You Why Your Kafka Consumer Is Lagging

Install

Basic Usage

What It Detects

Sample Output

SSL & SASL Support

.klagrc Config File

JSON Output

How It Works

What's Next

Links

How I Reduced Kafka Boilerplate by 90% with Curve - A Declarative Event Library for Spring Boot

The Problem: Too Much Boilerplate

The Solution: Just Add One Annotation

Key Features That Make It Production-Ready

1. Automatic PII Protection

2. 3-Tier Failure Recovery

3. Transactional Outbox Pattern

4. Built-in Observability

Architecture: Hexagonal Design

Performance

Quick Start

1. Add Dependency

2. Configure

3. Use

Lessons Learned

1. Hexagonal Architecture Was Worth It

2. Security Defaults Matter

3. Documentation Is Critical for Adoption

4. Maven Central Publishing Is Hard

Comparison with Alternatives

What's Next?

Roadmap for v1.0.0 (Q3 2026):

Try It Yourself

Contributing

Final Thoughts

8 Spring @Transactional Pitfalls That Break Production (And How to Catch Them All)

1. The Silent Killer: Same-Class Method Calls

2. The Private Method Trap

3. The Final Method Problem

4. The Checked Exception Surprise

5. The @async + @Transactional Conflict

6. Writing in readOnly Transactions

7. The N+1 Query Time Bomb

8. The Propagation Conflict Nightmare

The Problem: IDEs Don't Warn You

Introducing: Spring Transaction Inspector

Example in Action

The 8 Inspections

Installation

Via JetBrains Marketplace (Easiest)

Manual Installation

Configuration

Open Source & MIT Licensed

Real Impact

For Spring Boot Developers