1. Introduction

Micronaut is a modern, JVM-based framework designed for building lightweight, scalable, and cloud-native applications. It supports Java, Kotlin, and Groovy and provides features such as dependency injection, REST APIs, configuration management, HTTP clients, and microservice communication.

For developers familiar with Spring Boot, Micronaut offers a similar programming experience but takes a different approach to dependency injection and application initialization.

One of its main advantages is compile-time dependency injection, which reduces the need for runtime reflection and can improve application startup time and memory efficiency.

2. What Makes Micronaut Different?

Traditional dependency injection frameworks often discover and resolve dependencies at runtime.

Micronaut processes dependency injection metadata during compilation using annotation processors.

For example:

import jakarta.inject.Singleton;

@Singleton
public class PaymentService {

    public String processPayment() {
        return "Payment processed successfully";
    }
}

The @Singleton annotation tells Micronaut to manage the lifecycle of this class and provide a single instance within the application context.

Micronaut generates the necessary bean metadata during compilation rather than relying on extensive runtime classpath scanning and reflection.

3. Building a REST API with Micronaut

Let’s build a simple Payment Management API.

First, create a Micronaut application using the official Micronaut Launch website:

https://micronaut.io/launch/

Choose Java as the programming language and Maven as the build tool.

For this example, we will implement an endpoint that processes payment requests.

Step 1: Create a REST Controller

In Micronaut, controllers are defined using the @Controller annotation.

import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;

@Controller("/payments")
public class PaymentController {

    @Get("/status")
    public String getPaymentStatus() {
        return "Payment service is running";
    }
}

When the application starts, Micronaut registers this controller and exposes the following endpoint:

GET /payments/status

Response:

Payment service is running

Step 2: Implement Business Logic Using Dependency Injection

Instead of putting business logic directly inside the controller, we can create a separate service class.

import jakarta.inject.Singleton;

@Singleton
public class PaymentService {

    public String processPayment(double amount) {

        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Invalid payment amount"
            );
        }

        return "Payment of " + amount + " processed successfully";
    }
}

Now inject this service into the controller using constructor injection.

import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;
import io.micronaut.http.annotation.QueryValue;

@Controller("/payments")
public class PaymentController {

    private final PaymentService paymentService;

    public PaymentController(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    @Get("/process")
    public String processPayment(
            @QueryValue double amount) {

        return paymentService.processPayment(amount);
    }
}

Example request:

GET /payments/process?amount=1500

Response:

Payment of 1500.0 processed successfully

Notice that we did not manually create the PaymentService instance using new PaymentService(). Micronaut automatically injects the dependency.

This is similar to constructor-based dependency injection in Spring Boot.

4. Connecting to External Microservices

In a microservices architecture, services frequently communicate with other services through HTTP APIs.

Micronaut provides a declarative HTTP client using the @Client annotation.

For example, imagine our Payment Service needs to communicate with an external Customer Service.

import io.micronaut.http.annotation.Get;
import io.micronaut.http.client.annotation.Client;

@Client("http://localhost:8081")
public interface CustomerClient {

    @Get("/customers/{id}")
    String getCustomer(Long id);
}

We can inject this client into another service:

import jakarta.inject.Singleton;

@Singleton
public class CustomerService {

    private final CustomerClient customerClient;

    public CustomerService(CustomerClient customerClient) {
        this.customerClient = customerClient;
    }

    public String findCustomer(Long id) {
        return customerClient.getCustomer(id);
    }
}

Micronaut generates the implementation of the declarative client.

This reduces the amount of boilerplate code required to make HTTP requests between microservices.

5. Application Configuration

Like Spring Boot, Micronaut supports externalized application configuration through application.yml.

For example:

micronaut:
  application:
    name: payment-service

server:
  port: 8082

This configuration sets the application name and HTTP server port.

You can also inject custom configuration values into your services rather than hardcoding them.

6. Testing a Micronaut Application

Testing is an important part of backend development.

Micronaut provides integration with JUnit 5 through Micronaut Test.

Example:

import io.micronaut.test.extensions.junit5.annotation.MicronautTest;
import jakarta.inject.Inject;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

@MicronautTest
class PaymentServiceTest {

    @Inject
    PaymentService paymentService;

    @Test
    void shouldProcessPayment() {

        String result =
            paymentService.processPayment(1500);

        assertEquals(
            "Payment of 1500.0 processed successfully",
            result
        );
    }
}

The @MicronautTest annotation starts the application context, allowing dependencies to be injected during testing.

7. Micronaut vs Spring Boot

Both frameworks are excellent choices for building Java backend applications.

However, there are some architectural differences:

FeatureMicronautSpring BootDependency InjectionCompile-time metadataPrimarily runtime resolutionStartup PerformanceDesigned for fast startupDepends on application configurationMemory ConsumptionDesigned for lower overheadCan have higher runtime overheadREST API DevelopmentSupportedSupportedMicroservicesBuilt-in integrationsExtensive ecosystemTestingJUnit, SpockJUnit, Mockito

8. Conclusion

Micronaut is an interesting alternative to Spring Boot, particularly for developers building microservices and cloud-native applications.

Its compile-time dependency injection, declarative HTTP clients, configuration management, and testing support make it a framework worth exploring.

For developers already experienced with Java and Spring Boot, learning Micronaut should be relatively straightforward because many fundamental concepts remain familiar.

Rather than replacing Spring Boot in every scenario, Micronaut provides another option when startup performance, memory efficiency, and cloud-native deployment are important considerations.

Useful resources:

• Official website: https://micronaut.io/
• Documentation: https://docs.micronaut.io/
• Tutorials: https://guides.micronaut.io/

For years, Resilience4j has been a popular choice for making Spring Boot applications more resilient. Example : Circuit Breakers, Rate Limiting, Retry, Bulkhead etc.

But with Spring Framework 7, Spring now provides more built-in resilience capabilities.

So, do we still need Resilience4j?

Retry with Spring Framework 7

For temporary failures, Spring can now handle retries directly.

@Retryable(
    maxAttempts = 3,
    delay = 500
)
public PaymentResponse makePayment() {
    return paymentClient.call();
}

If the service temporarily fails:

For simple retry scenarios, you may not need Resilience4j.

Concurrency Limiting

Spring Framework 7 also introduces concurrency limiting.

@ConcurrencyLimit(50)
public PaymentResponse makePayment() {
    return paymentClient.call();
}

This limits how many calls can execute simultaneously, helping protect your service or a downstream dependency during traffic spikes.

Where Resilience4j Still Helps

A major example is the Circuit Breaker.

@CircuitBreaker(
    name = "paymentService",
    fallbackMethod = "fallback"
)
public PaymentResponse makePayment() {
    return paymentClient.call();
}

public PaymentResponse fallback(Throwable ex) {
    return new PaymentResponse("Payment service unavailable");
}

If the payment service keeps failing:

Retry and Circuit Breaker solve different problems:

Retry: “It might be a temporary problem. Try again.”

Circuit Breaker: “This service keeps failing. Stop calling it for a while.”

What Should You Use?

If you only need:

Retry + Concurrency Control

Spring Framework 7 may be enough.

If you need:

Retry
+ Circuit Breaker
+ Rate Limiting
+ Bulkhead
+ Time Limiter

Resilience4j is still very useful.

Final Thoughts

Spring Framework 7 doesn’t make Resilience4j obsolete.

It simply means we don’t need to add Resilience4j automatically to every Spring Boot application.

Use Spring’s built-in features for simpler resilience requirements. Use Resilience4j when you need more advanced patterns such as circuit breakers and rate limiting.

The real question isn’t:

“Do I still need Resilience4j?”

It’s:

“What kind of failures does my application need to survive?”

References

• Spring Framework 7.0 General Availability
• Spring Framework 7.0 Release Notes

For years, developers have faced a common dilemma when building REST APIs:

How do you send a complex, read-only query without misusing HTTP methods?

If you’ve ever created a /search endpoint using POST simply because your filters were too large for a URL, you're not alone.

After decades of discussion, the HTTP protocol finally has a standardized solution: the QUERY method.

In June 2026, the Internet Engineering Task Force (IETF) published RFC 10008, officially introducing the HTTP QUERY method.

Let’s explore why this matters and how it changes API design.

The Problem with GET

GET is designed for retrieving resources. It is Safe, Idempotent, Cache-friendly

A typical request looks like this:

GET /products?category=laptops&brand=Dell&minPrice=1000&maxPrice=2000

This works well for simple filters.

But real-world APIs often require much more.

Imagine searching products with:

• Multiple category selections
• Deeply nested logical filters
• Precise date and time ranges
• Advanced sorting options and pagination
• Complex boolean conditions (AND/OR logic)

Your URL quickly becomes unreadable.

GET /products?category=laptops&brand=Dell&brand=Lenovo&priceMin=1000&priceMax=2000&rating=4&availability=true&...

Besides readability, long URLs can exceed limits imposed by browsers, proxies, and web servers.

Why Not Just Use POST?

Most APIs solve this problem using POST.

POST /products/search
Content-Type: application/json

{
  "category": "laptops",
  "brands": ["Dell", "Lenovo"],
  "price": {
    "min": 1000,
    "max": 2000
  }
}

Although this works technically, it introduces semantic issues.

According to HTTP:

• POST is not guaranteed to be safe (it implies state modification).
• POST is not inherently idempotent (repeating the request blindly isn't safely guaranteed by network layers).

This means intermediaries, caches, and clients must assume the request could modify server state, even if your endpoint is only performing a search.

In other words, we’re using a write-oriented method for a read-only operation.

Enter the HTTP QUERY Method

The new QUERY method was created specifically for read-only requests that require a request body.

Example:

QUERY /products HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "category": "laptops",
  "brands": ["Dell", "Lenovo"],
  "price": {
    "min": 1000,
    "max": 2000
  },
  "sort": "price"
}

The important part is the semantics.

A QUERY request:

• Reads data only: It never changes the server state.
• Supports a request body: It allows complex JSON, XML, or SQL-like payloads.
• Is safe and idempotent: Intermediaries and clients can safely repeat the request if a network glitch occurs.

This is exactly what developers have wanted for years.

Why This Is a Big Deal

The HTTP protocol has anchored the web for over 30 years. Throughout its evolution, API designers have consistently been forced to compromise, choosing between misusing GET (bloating the URL) or misusing POST (breaking caching and semantics).

By providing a standardized way to express complex, payload-backed reads, QUERY radically improves:

• API Clarity: Endpoints instantly communicate their true intent.
• Security & Privacy: Sensitive parameters stay contained safely inside the request body rather than leaking into server logs.
• Tooling Optimization: CDNs and caching proxies can now natively optimize caching strategies for heavy read payloads using content negotiation headers like Accept-Query.

Final Thoughts

The introduction of the QUERY method may seem like a small addition to HTTP, but it addresses a problem developers have encountered for decades.

It allows APIs to express intent more accurately:

• GET for simple retrievals
• QUERY for complex read-only requests
• POST for creating or processing data

It’s a small change with the potential to improve API design across the web.

As ecosystem support grows, don’t be surprised if QUERY becomes the preferred method for complex search endpoints that have traditionally relied on POST.

References

• RFC 10008 — The HTTP QUERY Method (June 2026)
• HTTP Semantics (RFC 9110)

No subscriptions. No accounts. No data sent to anyone. Just open it and start invoicing. Link : https://invoicegeny.com/

If you run a small business, freelance, or do any kind of client work, invoicing is one of those necessary evils. You need professional-looking invoices, but the tools that create them either cost money every month, require you to create an account, or lock your data behind a login.

Invoicegeny is a free alternative that works differently. It runs entirely in your web browser. No sign-up, no subscription, no data ever leaving your device. Open it, set it up once, and start sending invoices in minutes.

Your Data Stays on Your Device

This is the biggest difference from every other invoicing tool.

Apps like FreshBooks, Wave, or QuickBooks store your business data on their servers. That means your client list, your pricing, your revenue, all of it lives somewhere you don’t fully control. If they change their pricing, get acquired, or shut down, you have a problem.

Invoicegeny stores everything in your browser’s local storage, the same place your browser saves your preferences and history. Nothing is sent to any server. Nothing is stored in the cloud. Your data is yours, period.

Set It Up Once, Use It Forever

The first thing you do is fill in your Seller Profile. This is your business info: name, logo, address, email, phone, tax ID, default tax rate, service charge, and bank account details. You fill this out once. Every invoice you create pulls from this profile automatically.

You can save multiple bank accounts and pick the right one per invoice with a single click. Currency is fully configurable — USD, EUR, GBP, LKR, and dozens more are supported out of the box.

Customers and Products - Managed, Not Re-Typed

One of the most tedious parts of manual invoicing is re-entering the same customer details and prices over and over.

Invoicegeny has a proper customer list and product catalogue. When you create an invoice, you search for the customer by name, phone, or email, it finds them instantly. Same with products: search, click, and the item appears on the invoice with the right price already filled in.

Adding the same product twice? It just bumps the quantity. No duplicate lines. If a customer or product doesn’t exist yet, you can add them right from the invoice creation screen,no need to go to a separate page first.

Create an Invoice in Under a Minute

Once your profile, customers, and products are set up, creating an invoice is straightforward: pick a customer, search and add products, choose a payment method (Cash, Card, or Bank Transfer), set a due date, add any notes, and click “Save & Download PDF”.

A professionally formatted PDF downloads to your computer instantly, with your logo, your business details, the itemised list, tax, service charge, and total. Ready to send to your client.

Invoice numbers are assigned automatically in sequence (INV-0001, INV-0002…) so you never have to think about it.

The PDF Looks Professional

A lot of free invoice tools produce PDFs that look like they were made in 2003. This one doesn’t.

The generated PDF includes your logo in the top left corner, your business name and contact details next to it, “INVOICE” prominently on the right with the invoice number and dates, a clean items table with alternating row shading, an itemised totals section showing subtotal, tax, service charge, and the final amount, payment details at the bottom, and a footer.

It’s the kind of invoice that makes you look established and professional, even if you’re a team of one.

Track the Status of Every Invoice

Your invoices list shows every invoice you’ve created with its current status: Draft, Sent, Paid, or Overdue. You can update the status with one click. It’s a simple but effective way to know at a glance what’s been paid and what you still need to chase.

Who Is This For?

This tool is a great fit if you are a freelancer (designer, developer, photographer, writer, consultant) who invoices clients directly, a sole trader or small business, someone who values privacy and doesn’t want their business data on third-party servers, someone tired of paying a monthly fee for a feature they only use occasionally, or operating in any country — multi-currency support is built in.

Completely Free. Forever.

There’s no free tier with limits. No premium plan. No credit card required. The tool has no server costs because it has no server. It’s free to use because there’s genuinely nothing to charge for.

Open the app, fill in your seller profile, add a couple of customers and products, create your first invoice, and download the PDF. The whole setup takes about five minutes. After that, invoicing takes under a minute per client.

To try you can visit → https://invoicegeny.com/

This article targets the beginner level java developers(Spring-Boot). If you’ve been writing Java code for a while, chances are you’ve fallen into this habit of wrapping everything up with try-catch blocks. As you keep going on you might have over used try-catch blocks. Excessive try-catch usage is often a sign of poor design rather than good error handling.

I’m not saying that try-catch blocks should be totally replaced but you should know when to use it and when not to.

In this article I will be covering 3 points that may help you,

1. Validate First — Let your request objects enforce rules using annotations instead of relying on exceptions for basic validation.
2. Hierarchy of Custom Exceptions — Define meaningful exceptions that represent real business problems.
3. Global Exception Handling with @ControllerAdvice –Centralize error handling instead of repeating it in every method.

At the end, I hope this may help you all to write better, redable and structured code.

1. Validate First

sometimes developers uses try-catch blocks to capture exceptions thrown because of invalid/bad inputs, Null inputs. For example you might have used a try catch to throw an exception when user enters an invalid email address.

@RestController
@RequestMapping("/users")
public class UserController {

    @PostMapping("/register")
    public ResponseEntity<String> registerUser(@RequestBody UserRequest request) {
        try {
            if (!request.getEmail().contains("@")) {
                throw new RuntimeException("Invalid email format");
            }

            if (request.getName() == null) {
                throw new NullPointerException("Name cannot be null");
            }

            // imagine saving the user here
            return ResponseEntity.ok("User registered successfully");

        } catch (Exception e) {
            return ResponseEntity.badRequest().body(e.getMessage());
        }
    }
}

instead of doing the above we can simply validate in the request object.

import jakarta.validation.constraints.Email;
import jakarta.validation.constraints.NotBlank;

public class UserRequest {

    @NotBlank(message = "Email is required")
    @Email(message = "Invalid email format")
    private String email;

    // getters & setters
}

2. Hierarchy of Custom Exceptions

Another common mistake is catching generic exceptions like Exception and trying to figure out what went wrong after the failure.

// generic exceptions will not tell you exactly what's wrong
try {
    userService.process(user);
} catch (Exception e) {
    logger.error("Something failed: " + e.getMessage());
    return ResponseEntity.internalServerError().build();
}

To fix this we can use pre written custom exceptions in java. Instead of catching everything, you can define exceptions that clearly describe the failure.

Base Exception

public class AppException extends RuntimeException {

    private final HttpStatus status;
    private final String errorCode;

    public AppException(String message, HttpStatus status, String errorCode) {
        super(message);
        this.status = status;
        this.errorCode = errorCode;
    }

    public HttpStatus getStatus() {
        return status;
    }

    public String getErrorCode() {
        return errorCode;
    }
}

Specific Exceptions

public class ProductNotFoundException extends AppException {
    public ProductNotFoundException(Long productId) {
        super("Product not found with id: " + productId,
              HttpStatus.NOT_FOUND,
              "PRODUCT_NOT_FOUND");
    }
}

public class ProductOutOfStockException extends AppException {
    public ProductOutOfStockException(String productName) {
        super("Product out of stock: " + productName,
              HttpStatus.CONFLICT,
              "PRODUCT_OUT_OF_STOCK");
    }
}

Usage in Service Layer

public Product purchaseProduct(Long productId) {

    Product product = productRepository.findById(productId)
        .orElseThrow(() -> new ProductNotFoundException(productId));

    if (product.getStock() <= 0) {
        throw new ProductOutOfStockException(product.getName());
    }

    product.setStock(product.getStock() - 1);
    return productRepository.save(product);
}

3. Global Exception Handling with @ControllerAdvice

As of now you have meaning full exceptions written the next thing to do is write a global exception handler to handle all exceptionjs at one place.

import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(AppException.class)
    public ResponseEntity<ErrorResponse> handleAppException(AppException ex) {
        ErrorResponse error = new ErrorResponse(
                ex.getErrorCode(),
                ex.getMessage()
        );
        return new ResponseEntity<>(error, ex.getStatus());
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGenericException(Exception ex) {
        ErrorResponse error = new ErrorResponse(
                "INTERNAL_ERROR",
                "Something went wrong"
        );
        return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

Error Response Model

public class ErrorResponse {
    private String code;
    private String message;

    public ErrorResponse(String code, String message) {
        this.code = code;
        this.message = message;
    }

    // getters & setters
}

Bonus: Retrying Operations Safely

Sometimes failures are transient. For example, calling a payment gateway or an external API may fail temporarily. Instead of wrapping everything in try-catch and manually retrying, Spring provides a clean way to handle retries using Spring Retry.

1. Add Spring Retry Dependency

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

Enable retry in your application:

import org.springframework.retry.annotation.EnableRetry;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableRetry
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

2. Retry on Specific Exceptions

import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Service;

@Service
public class PaymentService {

    @Retryable(
        value = { NetworkException.class },  // Retry only on this exception
        maxAttempts = 3,                     // Try 3 times
        backoff = @Backoff(delay = 2000)     // Wait 2 seconds between retries
    )
    public void processPayment(Order order) {
        // Fake API Call
        if (Math.random() < 0.7) {
            throw new NetworkException("Temporary network failure");
        }
        System.out.println("Payment processed successfully for order: " + order.getId());
    }
}

3. Optional: Handle Retry Exhaustion

You can catch the failure after all retries are exhausted using @Recover:

import org.springframework.retry.annotation.Recover;

@Recover
public void recover(NetworkException e, Order order) {
    // Log and take alternate action
    System.out.println("Failed after retries: " + e.getMessage() + " for order " + order.getId());
}

Note : Don’t retry all exceptions blindly. Only transient, recoverable errors should be retried, permanent failures like validation errors should fail fast.

Summary

Try-catch is not bad, over using and also misusing it is bad.

References

• Spring Boot Official Documentation — Validation
• Jakarta Bean Validation (JSR 380)
• Spring Boot Exception Handling with @ControllerAdvice
• Building a Custom Exception Hierarchy in Java
• Spring Retry — Declarative Retry for Spring Applications

In the ever-evolving world of programming languages, simplicity often gets overshadowed by complexity and “powerful” features. However, simplicity is what makes software scalable, maintainable, and enjoyable to build. That’s where Go (or Golang) truly shines.

👋 Why I Started Learning Go as a Java Developer

After spending over 5 years building large-scale applications in Java, especially with Spring Boot, I found myself becoming increasingly aware of certain limitations:

• Verbose boilerplate code, even with Lombok and annotations
• Heavy runtime requirements with the JVM
• Complex thread management for concurrency
• Slower startup and larger memory usage, especially for microservices

While Java remains an incredibly powerful and mature language, I was looking for something more lightweight — something that could handle concurrency elegantly, compile into a single binary, and reduce development overhead for smaller services and tools.

That’s when I decided to give Go a try.

My first Go project was a small REST API(CRUD) that fetched data from an external service, processed it, and stored it in a database. To my surprise:

• The code was minimal and easy to read.
• The concurrency model (goroutines and channels) felt natural.
• The final binary was compact and deployable without Docker or JVM.

1. Minimal Syntax, Maximum Clarity

Go’s syntax is clean, concise, and consistent. If you’ve worked with Java, Go might feel refreshing.

Compare a simple “Hello, World!” in Java:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

Now in Go:

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

No boilerplate. No classes. Just main and fmt.

2. One Way to Do Things

Unlike languages that offer multiple ways to solve the same problem, Go deliberately provides just one right way.

• No inheritance (use composition)
• No exceptions (explicit error handling)
• No annotations, generics (until very recently), or reflection-heavy frameworks

This makes reading other people’s code as easy as reading your own.

3. Built-in Concurrency with Goroutines

Concurrency in Java often involves managing threads, thread pools, and synchronization. Go simplifies it with goroutines and channels.

go doSomething() // runs in the background

And communication between goroutines:

ch := make(chan string)

go func() {
    ch <- "Hello from goroutine"
}()

msg := <-ch
fmt.Println(msg)

No thread management. No race conditions (if used well). Just elegant concurrency.

4. Fast Compilation and Deployment

Go compiles directly to machine code, producing a single binary. No JARs, WARs, or runtime dependencies.

go build main.go
./main

This makes it ideal for Docker containers, small services, or CLI tools where minimalism matters.

5. Simpler Dependency Management

Go Modules (go mod) make dependency management straightforward:

go mod init myapp
go get github.com/gin-gonic/gin

No XML files, no complex build systems — just go.mod and go.sum.

6. Rich Standard Library

The standard library covers everything from HTTP, JSON, and I/O to encryption and testing. You can build a web server with a few lines:

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Welcome to Go!")
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

7. Explicit Error Handling

Go favors explicit error handling over exceptions. While some find it verbose at first, it promotes clear and predictable error paths.

val, err := doSomething()
if err != nil {
    return err
}

Less magic, more control.

Final Thoughts

Go doesn’t try to be everything. It focuses on being simple, fast, and readable — the traits that many large languages slowly lose over time.

For me, as a Java developer, learning Go was refreshing. It reminded me of why I started programming in the first place: to build things quickly, efficiently, and enjoyably.

🚀 Want to Try Go?

• Install Go: https://golang.org/dl/
• Try it in browser: https://play.golang.org/

Complex objects with lots of fields, particularly optional ones, can easily become chaotic. The Builder Pattern is useful in this situation. It makes it possible to create objects that are neat, readable, and maintainable — especially in Java, where named parameters are not used.

In this blog I’ll be covering:

• What the Builder Pattern is
• When to use it
• How to implement it in Java
• Bonus: How Lombok makes this even simpler in Spring Boot projects

What is the Builder Pattern?

The Builder Pattern is a creational design pattern that lets you construct complex objects step by step. It separates the construction of an object from its representation, allowing the same construction process to create different representations.

Example of a constructor problem:

public class User {
    private String firstName;
    private String lastName;
    private int age;
    private String phone;
    private String address;
}

Now let’s see what happens when we have multiple constructors with different combinations of these fields?

new User("Tharindu", "Fernando");
new User("Tharindu", "Fernando", 30);
new User("Tharindu", "Fernando", 30, "0771234567");

• In the above case, Constructor overloads are everywhere — so the code is not clean! This will get ugly fast.

Solution: The Builder Pattern

In Java we can write a Builder :

User user = User.builder()
                .firstName("Tharindu")
                .lastName("Fernando")
                .age(30)
                .phone("0771234567")
                .address("Negombo,Sri Lanka")
                .build();

Clean. Readable. No constructor chaos.

Let’s see how to Implement Builder Pattern Manually

1. POJO with Builder

public class User {

    private String firstName;
    private String lastName;
    private int age;
    private String phone;
    private String address;

    private User(Builder builder) {
        this.firstName = builder.firstName;
        this.lastName = builder.lastName;
        this.age = builder.age;
        this.phone = builder.phone;
        this.address = builder.address;
    }

    public static Builder builder() {
        return new Builder();
    }

    public static class Builder {
        private String firstName;
        private String lastName;
        private int age;
        private String phone;
        private String address;

        public Builder firstName(String firstName) {
            this.firstName = firstName;
            return this;
        }

        public Builder lastName(String lastName) {
            this.lastName = lastName;
            return this;
        }

        public Builder age(int age) {
            this.age = age;
            return this;
        }

        public Builder phone(String phone) {
            this.phone = phone;
            return this;
        }

        public Builder address(String address) {
            this.address = address;
            return this;
        }

        public User build() {
            return new User(this);
        }
    }
}

2. Usage in Spring Boot Service

@Service
public class RegistrationService {
    public User registerUser() {
        return User.builder()
                .firstName("Tharindu")
                .lastName("Fernando")
                .age(25)
                .address("Colombo")
                .build();
    }
}

⚡ Shortcut: Using Lombok’s @Builder in Spring Boot

Spring Boot projects often use Project Lombok to reduce boilerplate.

import lombok.Builder;
import lombok.Data;

@Data
@Builder
public class User {
    private String firstName;
    private String lastName;
    private int age;
    private String phone;
    private String address;
}

And usage remains the same:

User user = User.builder()
                .firstName("Mark")
                .lastName("Anthony")
                .age(32)
                .build();

No need to write the builder class manually — clean and efficient.

Conclusion

The Builder Pattern is an essential design pattern in a Java developer’s toolkit, especially for Spring Boot applications where clean, maintainable code is key.

References

• @Builder
• Builder

The Problem

Recently, while working on a high-traffic Spring Boot application, I noticed some performance bottlenecks, particularly in response times for larger payloads. Users were experiencing slower page loads, especially during peak traffic. This became a critical issue as our application serves real-time data, and latency directly impacted user experience.

After analyzing the application, it became evident that our API responses were quite large — often exceeding several megabytes. This was especially true for endpoints returning lists of data or complex JSON objects. The challenge was clear: how could we reduce the response size without altering the actual data structure?

The Search for a Solution

Initially, we tried optimizing database queries and refactoring some heavy methods, but the results were not significant enough. That’s when I came across Gzip compression, a technique to minimize payload size during data transfer. Gzip is widely supported by modern browsers and API clients, and Spring Boot offers built-in support for it.

Implementing Gzip Compression in Spring Boot

To enable Gzip compression in our Spring Boot application, I added the following configurations to application.properties:

server.compression.enabled=true
server.compression.mime-types=application/json,application/xml,text/html,text/plain
server.compression.min-response-size=1024

Explanation:

• server.compression.enabled: This enables Gzip compression.
• server.compression.mime-types: Specifies the types of responses to compress (JSON, XML, HTML, Plain text).
• server.compression.min-response-size: Sets the minimum response size (in bytes) to trigger compression.

Within minutes of deploying these changes, I tested the API using Postman and saw immediate improvements. A typical JSON response that was previously around 2 MB dropped to around 500 KB — a 75% reduction in size.

Example of Unnecessary Payload vs. Compressed Payload

To better understand the impact, let’s look at an example. Suppose we have an endpoint that responds with a large JSON object:

{
  "userId": 456,
  "name": "James Arthur",
  "email": "james.arthur@gmail.com",
  "orders": [
    {
      "orderId": 10,
      "product": "Tablet",
      "price": 600,
      "description": "A high-resolution tablet with 10-inch display and 128GB storage."
    },
    {
      "orderId": 11,
      "product": "Headphones",
      "price": 150,
      "description": "Wireless noise-cancelling headphones with 30-hour battery life."
    },
    {
      "orderId": 12,
      "product": "Smartwatch",
      "price": 300,
      "description": "A smartwatch with fitness tracking and mobile connectivity."
    }
  ]
}
}

Without Gzip compression, this payload may consume around 2 KB of data. With Gzip enabled, it compresses down to 500 bytes or less, demonstrating a 75% reduction.

Proof of Reduction:

To verify, you can use the following curl commands:

Without Gzip:

curl -H "Accept-Encoding: identity" -w "
Size: %{size_download} bytes
" -o /dev/null http://localhost:8080/api/test

With Gzip:

curl -H "Accept-Encoding: gzip" -w "
Size: %{size_download} bytes
" -o /dev/null http://localhost:8080/api/test

You should observe a significant difference in the size_download value between the two requests. This is a clear indication of how Gzip optimizes network bandwidth and enhances response times.

Verifying the Improvement

To validate, I used the following curl command to inspect the headers:

curl -H "Accept-Encoding: gzip" -I http://localhost:8080/api/test

The response headers included:

Content-Encoding: gzip

Additionally, the browser’s Developer Tools → Network tab showed the reduced size of the compressed response.

Applying Gzip Compression for Specific Endpoints

While enabling Gzip globally is straightforward, there are cases where you might want to compress only specific endpoints. This is particularly useful if you want to avoid the CPU overhead for certain responses or exclude endpoints that handle already compressed data.

Custom Filter for Endpoint-Based Gzip Compression

We can create a Servlet Filter that selectively applies Gzip only for specific paths.

GzipResponseFilter.java:

import jakarta.servlet.Filter;
import jakarta.servlet.FilterChain;
import jakarta.servlet.FilterConfig;
import jakarta.servlet.ServletException;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.zip.GZIPOutputStream;

public class GzipResponseFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        // Specify the endpoints where Gzip should be applied
        String requestURI = request.getServletContext().getContextPath();
        if (requestURI.startsWith("/api/user")) {
            httpResponse.addHeader("Content-Encoding", "gzip");
            GZIPResponseWrapper gzipResponseWrapper = new GZIPResponseWrapper(httpResponse);
            chain.doFilter(request, gzipResponseWrapper);
            gzipResponseWrapper.close();
        } else {
            chain.doFilter(request, response);
        }
    }

    @Override
    public void destroy() {}
}

GZIPResponseWrapper.java:

import jakarta.servlet.http.HttpServletResponse;
import jakarta.servlet.http.HttpServletResponseWrapper;
import java.io.IOException;
import java.io.OutputStream;
import java.util.zip.GZIPOutputStream;

public class GZIPResponseWrapper extends HttpServletResponseWrapper {

    private GZIPOutputStream gzipOutputStream;

    public GZIPResponseWrapper(HttpServletResponse response) throws IOException {
        super(response);
        this.gzipOutputStream = new GZIPOutputStream(response.getOutputStream());
    }

    @Override
    public OutputStream getOutputStream() throws IOException {
        return gzipOutputStream;
    }

    @Override
    public void flushBuffer() throws IOException {
        gzipOutputStream.flush();
    }

    @Override
    public void close() throws IOException {
        gzipOutputStream.close();
    }
}

WebConfig.java:

import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class WebConfig {

    @Bean
    public FilterRegistrationBean<GzipResponseFilter> gzipFilter() {
        FilterRegistrationBean<GzipResponseFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new GzipResponseFilter());
        registrationBean.addUrlPatterns("/api/user/*");
        return registrationBean;
    }
}

How It Works:

• The filter intercepts HTTP responses for endpoints that start with /api/user/*.
• Gzip compression is applied only to those specific URIs, reducing unnecessary overhead for other routes.
• This approach allows granular control over what gets compressed.

Now you have the flexibility to compress only what matters and avoid unnecessary CPU consumption.

Real-World Impact

Enabling Gzip compression not only improved response times but also reduced bandwidth usage, resulting in cost savings. Users reported smoother and faster load times, even on slower networks. This simple configuration turned out to be a game-changer for our application’s performance.

Potential Drawbacks of Gzip Compression

While Gzip offers significant benefits, there are some drawbacks to consider:

1. Increased CPU Usage:
   Compression is a CPU-intensive operation. For high-traffic applications, enabling Gzip can lead to increased CPU usage as each response needs to be compressed before being sent.
2. Minimal Benefit for Already Compressed Files:
   File types like images (.jpg, .png, .gif) and compressed assets (.zip, .mp4) are already optimized, and applying Gzip provides almost no reduction in size while still consuming CPU.
3. Latency for Small Responses:
   If the response payload is small (e.g., less than 1 KB), the overhead of compression and decompression can actually increase the response time slightly. This is why Spring Boot allows you to set a minimum size threshold.

Conclusion

What started as a frustrating performance bottleneck turned into a learning opportunity. Gzip compression, with just a few lines of configuration, enhanced our Spring Boot application’s efficiency remarkably. If you’re facing similar issues with large payloads and sluggish response times, enabling Gzip might be the optimization you’re looking for.

References

The gzip home page

https://www.baeldung.com/spring-resttemplate-compressing-requests

Github : https://github.com/tharindu1998/gzip-springboot-example

In transactional systems, deadlocks are a common concurrency issue, particularly when several threads or processes seek for the same resources. Deadlocks can cause major problems with application speed and consistency in Spring Boot applications that use relational databases and @Transactional annotations.

In this blog post, we will cover:

• What a deadlock is
• How it occurs in Spring Boot transactional systems
• Real code examples
• How to detect and handle deadlocks
• Best practices to prevent them

What is a Deadlock?

A deadlock occurs when two or more transactions block each other by holding a lock and waiting for the other’s lock to be released.

Example:

• Transaction A locks Row 1 and needs Row 2
• Transaction B locks Row 2 and needs Row 1
• Neither can proceed, resulting in a deadlock

Relational databases (like MySQL, PostgreSQL) will detect the deadlock and typically abort one of the transactions, throwing an exception.

Deadlock in Spring Boot Example

Let’s consider a simple scenario using Spring Data JPA and @Transactional.

Model :

@Entity
public class Account {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private String email;

    private BigDecimal balance;

    // getters and setters
}

Repository :

public interface AccountRepository extends JpaRepository<Account, Long> {}

Service with Transaction :

@Service
public class AccountService {

    @Autowired
    private AccountRepository accountRepository;

    //this method will cause deadlocks if two threads access the transfer method at the same time.
    //If both threads fetch and lock their first account row and then,
    //attempt to access the other, a deadlock is likely.
    @Transactional
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        Account from = accountRepository.findById(fromId).orElseThrow();
        Account to = accountRepository.findById(toId).orElseThrow();

        from.setBalance(from.getBalance().subtract(amount));
        to.setBalance(to.getBalance().add(amount));

        accountRepository.save(from);
        accountRepository.save(to);
    }

• Thread A: transfers from Account 1 to 2
• Thread B: transfers from Account 2 to 1

How to Detect Deadlocks

1. Database Logs

Databases like MySQL and PostgreSQL will log deadlocks. For example, in MySQL, you can run:

SHOW ENGINE INNODB STATUS;

2. Application Logs

Spring will typically throw a DeadlockLoserDataAccessException or a database-specific exception. Make sure your logs include stack traces.

How to Handle and Prevent Deadlocks

1. Consistent Lock Ordering

Always access resources in the same order. In the above example, always load accounts in order of ID:

    @Transactional
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        List<Account> accounts = accountRepository.findAllById(List.of(fromId, toId));
        Account from = fromId < toId ? accounts.get(0) : accounts.get(1);
        Account to = fromId < toId ? accounts.get(1) : accounts.get(0);

        accountRepository.save(from);
        accountRepository.save(to);
    }

2. Retry Logic on Deadlocks

Use Spring’s @Transactional with retry logic using @Retryable from Spring Retry:

    @Retryable(
            value = {TransientDataAccessException.class},
            maxAttempts = 3,
            backoff = @Backoff(delay = 200))
    @Transactional
    public void transfer2(Long fromId, Long toId, BigDecimal amount) {
        Account from = accountRepository.findById(fromId).orElseThrow();
        Account to = accountRepository.findById(toId).orElseThrow();

        from.setBalance(from.getBalance().subtract(amount));
        to.setBalance(to.getBalance().add(amount));

        accountRepository.save(from);
        accountRepository.save(to);
    }

Don’t forget to enable Spring Retry:

@EnableRetry
@SpringBootApplication
public class DeadlockexampleApplication {

 public static void main(String[] args) {
  SpringApplication.run(DeadlockexampleApplication.class, args);
 }

}

• value and include are deprecated in latest versions so you can Define retry behavior via a RetryPolicy bean.

@Configuration
@EnableRetry
public class RetryConfig {

    @Bean
    public RetryPolicy retryPolicy() {
        SimpleRetryPolicy policy = new SimpleRetryPolicy();
        policy.setMaxAttempts(3);
        policy.setRetryableExceptions(Map.of(
            TransientDataAccessException.class, true
        ));
        return policy;
    }

    @Bean
    public RetryTemplate retryTemplate(RetryPolicy retryPolicy) {
        RetryTemplate template = new RetryTemplate();
        template.setRetryPolicy(retryPolicy);
        return template;
    }
}

3. Locking Strategies

Repository:

@Repository
public interface AccountRepository extends JpaRepository<Account, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT a FROM Account a WHERE a.id = :id")
    Account findByIdForUpdate(@Param("id") Long id);

}

Service:

    @Transactional
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        Account from = accountRepository.findByIdForUpdate(fromId);
        Account to = accountRepository.findByIdForUpdate(toId);

        from.setBalance(from.getBalance().subtract(amount));
        to.setBalance(to.getBalance().add(amount));

        accountRepository.save(from);
        accountRepository.save(to);
    }

Important Notes:

• Pessimistic locking tells the database to acquire a row-level write lock as soon as the row is read — no other transaction can read/write it until the current one commits or rolls back.
• This works well to prevent deadlocks, but can cause blocking and contention under high load. So use it carefully.
• Always make sure you’re using it inside a @Transactional method — otherwise, the lock will be released immediately after the method exits.

4. Keep Transactions Short

Avoid long-running transactions. Don’t perform unnecessary logic inside a transaction block.

Conclusion

Deadlocks are inevitable in highly concurrent systems, but with careful design, detection, and retries, you can manage them effectively in Spring Boot. Stick to consistent access patterns, use proper locking, and ensure your application is resilient to deadlocks through retries and monitoring.

References

https://www.baeldung.com/spring-retry

https://www.baeldung.com/java-deadlock-livelock

https://www.baeldung.com/transaction-configuration-with-jpa-and-spring

GitHub : https://github.com/tharindu1998/resolve-deadlock-example

In modern Microservices Architecture, data integrity and reliability are non-negotiable. Specially when you are dealing with SQL. This is where ACID(Atomicity, Consistency, Isolation and Durability) principles comes into play.

Although you may understand these principles, it is really important to leverage them to increase system performance.Let’s break it down in the context of a Spring Boot app with a relational database like PostgreSQL or MySQL.

What Are ACID Properties?

1. Atomicity - A transaction is all-or-nothing. Either all changes succeed or none do.

• Use Case: Booking a caregiver and updating availability must both succeed — or both fail.

2. Consistency - Data must always be in a valid state before and after the transaction.

• Use Case: A caregiver should never be double-booked.

3. Isolation - Transactions should not interfere with each other. Concurrency must not violate correctness.

• Use Case: Two clients booking the same caregiver at the same time shouldn’t both succeed.

4. Durability - Once a transaction is committed, it stays even after system failure.

• Use Case: A confirmed booking should persist even if the server crashes immediately after.

Let’s look into some code level Applications,

1.Atomicity in SpringBoot.

Use Spring’s @Transactional annotation to wrap multiple operations into a single atomic unit.

@Transactional
public void bookCaregiver(Long caregiverId, Long userId) {
    updateAvailability(caregiverId);
    createBooking(caregiverId, userId);
}

Optimization Tip: Avoid overusing @Transactional on read-heavy operations to reduce overhead.

2. Ensuring Consistency

Use database constraints (foreign keys, check constraints) and validation at both application and DB layers.

• Use Spring Validator + Hibernate Validator (JSR-380).
• Enforce DB-level constraints for additional safety.

@Column(nullable = false)
@NotNull
private LocalDate bookingDate;

Optimization Tip: Push validation upstream — validate early (at API layer) to avoid costly DB rollbacks.

3. Isolation for Concurrency Control

Spring Boot lets you define transaction isolation levels using @Transactional.

@Transactional(isolation = Isolation.SERIALIZABLE)

Isolation Levels:

• READ_COMMITTED -Prevents Dirty reads (Reading data from a transaction that hasn’t been committed yet.)
• REPEATABLE_READ -Prevents Dirty Reads + Non-Repeatable Reads(Ensures that if you read a row once, you’ll get the same data if you read it again within the same transaction, even if other transactions commit changes.)
• SERIALIZABLE- Prevents Dirty Reads + Non-Repeatable Reads + Phantom Reads(new rows matching the query condition might appear if another transaction inserts them.)

Optimization Tip: Use REPEATABLE_READ or READ_COMMITTED unless absolute isolation is needed—SERIALIZABLE may hurt performance.

4. Durability through Logging and Replication

Most relational databases (e.g., PostgreSQL, MySQL) ensure durability via WAL (Write-Ahead Logs) and disk flushing.

In Spring Boot, durability is mostly the job of the database and hardware — but you can support it:

• Use proper DB replication (e.g., master-slave setup).
• Use persistent queues (Kafka, RabbitMQ) for critical flows before writing to DB.

Bonus → Real-world Practices to Optimize for ACID in Spring Boot

Conclusion

Understanding and leveraging ACID principles isn’t just about following theory — it’s about making practical, high-impact architectural decisions. In your Spring Boot applications:

• Use transactions wisely.
• Choose the right isolation level.
• Validate data early.
• Embrace eventual consistency where possible.

By doing this, you not only ensure data integrity but also improve scalability, maintainability, and system resilience.

REFERENCES

• ACID Properties in DBMS Explained
• What are ACID Transactions?