Table of Contents

1. Why Docker + AWS for JMeter?
2. What We’ll Build (Architecture)
3. Prerequisites
4. Project Layout
5. Dockerfile (containerizing JMeter)
6. Docker Build
7. docker-compose.yml (one-command runs)
8. Local Dry-Run (optional)
9. Create Task Definition
10. Create Cluster and Run Task
11. Result S3

Why Docker + AWS for JMeter?

• Reproducible: same image, same runtime, fewer “works on my machine” issues.
• Portable: local dev, EC2, or CI — identical command.
• Automatable: compose brings one-line runs; S3 stores artifacts cleanly.

**We don’t cover the JMeter script (.jmx) itself. Assume you already have a valid plan.

In our QA infrastructure at iyzico, running JMeter directly on EC2 or local machines used to create inconsistency — plugin mismatches, Java versions, and path issues. Containerizing the environment solved all of these, and we could finally reproduce load runs identically across local, staging, and production-like setups.

What We’ll Build (Architecture)

• A single Docker image that contains JMeter CLI + (optional) plugins.
• A compose service that runs the plan headlessly, generates HTML report, and uploads artifacts to S3.
• An EC2 instance (Amazon Linux) with Docker/Compose installed; optional IAM role grants S3 PutObject.

Flow:
Local Environment(optional build) → EC2 (compose up) → JMeter runs → JTL + HTML report → ZIP → S3

This approach was driven by a need to simplify how we trigger performance tests in CI/CD. Instead of maintaining multiple AMIs or EC2 setup scripts, everything now lives in a single image definition. When a new feature needs stress testing, the team can launch a task definition directly — no manual setup, no SSH.

Prerequisites

• An AWS account and an S3 bucket (e.g., my-loadtests).
• I AM permissions:
  EC2 path: an Instance Profile (role) with s3:PutObject for your bucket/prefix.
• ECS path: a Task Role with s3:PutObject; an Execution Role for ECR pull & logs.
• (ECS only) An ECR repository to store your image; a VPC with subnets & a security group.
• Local Docker and docker compose (for build & optional dry-run)

Project Layout

jmeter-aws/
  Dockerfile
  docker-compose.yml
  jmeter/
    test.jmx                  # your existing JMeter test plan (left as-is)
    user.properties           # optional JMeter overrides
    data.csv                  # optional data file
  results/                    # mounted by compose (JTL, logs, HTML here)

Dockerfile (containerizing JMeter)

A minimal yet practical image (includes AWS CLI and popular plugins; remove plugins if you don’t need them).

# Dockerfile
FROM adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.18_10

USER root  

# (Optional) Plugins Manager + cmdrunner, then install a couple of common plugins
RUN apk update && \
    apk add --update --no-cache curl py-pip && \
    apk add ca-certificates && \
    update-ca-certificates && \
    pip install --upgrade --user awscli

# Set variables
ENV JMETER_HOME=/usr/share/apache-jmeter \
    JMETER_VERSION=5.6.2 \
    TEST_SCRIPT_FILE=test.jmx \
    TEST_RESULT_DIR=/var/jmeter \
    TEST_LOG_FILE=/var/jmeter/test.log \
    TEST_RESULTS_FILE=/var/jmeter/test-result.csv \
    TEST_REPORT_DIR=/var/jmeter/result/html-report \
    THREAD_GROUP_NAME="thread name" \
    VARIABLE="value"

# Install Apache JMeter
RUN wget http://archive.apache.org/dist/jmeter/binaries/apache-jmeter-${JMETER_VERSION}.tgz && \
    tar zxvf apache-jmeter-${JMETER_VERSION}.tgz && \
    rm -f apache-jmeter-${JMETER_VERSION}.tgz && \
    mv apache-jmeter-${JMETER_VERSION} ${JMETER_HOME}

ENV PATH="$JMETER_HOME/bin:$PATH"

# Copy jmeter files
ADD jmeter/script /var/jmeter/

WORKDIR /loadtest
COPY plan/ ./plan/
COPY run.sh ./run.sh
RUN chmod +x ./run.sh

# - Start the JMeter script
CMD echo -n > $TEST_LOG_FILE && \
    echo -n > $TEST_RESULTS_FILE && \
    export PATH=~/.local/bin:$PATH && \
    . ./usr/local/bin/set_submerchant_detail.sh && \
    $JMETER_HOME/bin/jmeter -n \
    -t=/var/jmeter/$TEST_SCRIPT_FILE \
    -j=$TEST_LOG_FILE \
    -l=$TEST_RESULTS_FILE \
    -JthreadGroupName=$THREAD_GROUP_NAME \
    -JrandomVariableForTest=$VARIABLE && \
    echo -e "\n\n===== UPLOADING THE FILES TO AWS S3 =====\n\n" && \
    aws s3 cp $TEST_LOG_FILE s3://performance-test-logging/uploads/$THREAD_GROUP_NAME/ && \
    aws s3 cp $TEST_RESULTS_FILE s3://performance-test-logging/uploads/$THREAD_GROUP_NAME/ && \
    aws s3 cp $TEST_REPORT_DIR s3://performance-test-logging/uploads/$THREAD_GROUP_NAME/ --recursive && \
    echo -e "\n\n===== UPLOAD COMPLETED SUCCESSFULLY =====\n\n"

Docker Build

Build locally; optionally tag for ECR:

# local build
docker build -t jmeter-aws:latest .

# optional multi-arch (if you need both amd64/arm64)
# docker buildx create --use
# docker buildx build --platform linux/amd64,linux/arm64 -t <account>.dkr.ecr.<region>.amazonaws.com/jmeter-aws:latest --push .

# tag for ECR (single-arch path)
aws ecr get-login-password --region <region> | \
  docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com
docker tag jmeter-aws:latest <account>.dkr.ecr.<region>.amazonaws.com/jmeter-aws:latest
docker push <account>.dkr.ecr.<region>.amazonaws.com/jmeter-aws:latest

Docker-compose.yml (one-command runs)

Environment variables let you tweak runs without touching the JMX.

# docker-compose.yml
version: "3.8"

services:
  jmeter:
    build: .
    image: docker-image:latest
    platform: linux/amd64
    environment:
      AWS_REGION: "eu-central-1"
      S3_BUCKET: "my-loadtests"                    # leave empty to skip upload
      S3_PREFIX: "runs/${COMPOSE_PROJECT_NAME:-local}"
      THREAD_GROUP_NAME: "thread_group_name"
      VARIABLE: "value"
    volumes:
      - ./results:/loadtest/results

Local Dry-Run (optional)

docker-compose -f <docker-compose_filePath> up <service_name>

#docker-compose -f docker-compose.yml up jmeter

Create Task Definition

1- ECR: push your image (see DockerBuild).

2- I am Roles:

• Task Role: allow s3:PutObject to arn:aws:s3:::my-loadtests/*.
• Execution Role: standard AmazonECSTaskExecutionRolePolicy (pull from ECR, push logs)

3- Task Definition (Linux): example container def (JSON gist):

{
  "family": "jmeter-aws",
  "networkMode": "awsvpc",
  "cpu": "1024",
  "memory": "2048",
  "executionRoleArn": "arn:aws:iam::<account>:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::<account>:role/jmeterS3TaskRole",
  "containerDefinitions": [
    {
      "name": "jmeter",
      "image": "<account>.dkr.ecr.<region>.amazonaws.com/jmeter-aws:latest",
      "essential": true,
      "environment": [
        { "name": "AWS_REGION", "value": "<region>" },
        { "name": "S3_BUCKET", "value": "my-loadtests" },
        { "name": "S3_PREFIX", "value": "runs/ecs" },
        { "name": "THREAD_GROUP_NAME", "value": "threadh group name" },
          ....        
        { "name": "EXTRA_JMETER_ARGS", "value": "-Jthreads=200 -Jduration=180 -Jjmeter.reportgenerator.overall_granularity=1000" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/jmeter-aws",
          "awslogs-region": "<region>",
          "awslogs-stream-prefix": "jmeter"
        }
      }
    }
  ]
}

Create Cluster and Run Task

1. Create an ECS cluster
2. Run Task (one-off):

• VPC/Subnets: public (assign public IP) or private + NAT
• Security group: egress allowed
• Task overrides (optional): tweak EXTRA_JMETER_ARGS for this run

3. Watch CloudWatch Logs stream for progress. The container exist when finished.

Result S3

Verify upload:

aws s3 ls s3://my-loadtests/runs/ecs/
# report-YYYYMMDD-HHMMSS.zip

Download & inspect:

aws s3 cp s3://my-loadtests/runs/ecs/report-YYYYMMDD-HHMMSS.zip .
unzip report-YYYYMMDD-HHMMSS.zip
# open report/index.html in your browser

That’s it. You now have a script-agnostic, containerized way to run JMeter locally, on EC2, or serverlessly via ECS — always shipping clean artifacts to S3.

In real practice, this setup has helped us reduce setup time by more than 70%. Every test run produces a clean HTML report in S3 with timestamped folders, which makes trend comparison effortless.

If you’re dealing with multiple environments or distributed teams, this containerized JMeter pattern is one of the most maintainable ways to keep load testing consistent and auditable.

Run JMeter Load Tests on AWS with Docker & Compose was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

To build reliable software, we need to ensure our code works correctly through testing. Unit testing checks the smallest individual pieces of code in isolation, such as a single function or statement. Integration testing ensures that these different pieces, and even external services like databases or message queues work together as expected.

With integration testing we can prevent critical failures in production by detecting and fixing bugs before deployment. Also, when refactoring code that spans multiple components, integration tests ensure that these changes don’t affect existing functionality.

What are Testcontainers? What do they solve and how do they work?

Testcontainers allows us to programmatically control and manage lightweight, disposable instances of common services (databases, message brokers, web browsers, or basically anything else that can run in a Docker container) directly from the test code. Testcontainers provide us an isolated test environment, each test suite gets its own containerized services, eliminating the “works on my machine” problem that often frustrates development teams :)

For example, instead of using in-memory databases like H2 that might behave differently from your production database, Testcontainers spin up actual database instances (PostgreSQL, MySQL, etc.) in Docker containers. This ensures your tests run against the same database engine you use in production, catching database-specific issues that mock databases might miss. With Testcontainers we can test against the exact same versions of databases, message queues, caches, and other services that we use in production.

How It Works Under the Hood

Testcontainers acts as a smart controller for Docker. When you run your tests, it follows a simple but powerful lifecycle:

1. Declaration: In your test code, you declare a requirement for a service by defining a @Container, like PostgreSQL.
2. Image Check & Pull: Testcontainers checks if the specified Docker image (e.g., postgres:latest) is available locally. If not, it automatically pulls it from Docker Hub.
3. Container Start: It then starts a new container from that image, creating a fresh, isolated instance of your service.
4. Dynamic Discovery: Once the container is running, Testcontainers inspects it to find the dynamically assigned port and any generated credentials. This is crucial for avoiding port conflicts on your machine.
5. Property Injection: It injects these connection details (the JDBC URL, username, and password) into the Spring application context, allowing your application to connect to the new container.
6. Automatic Cleanup: After your tests are complete, Testcontainers automatically stops and removes the container, ensuring a clean environment for the next run.

How to set up Testcontainers for a Spring Boot project?

Assuming we have Docker installed on our machine, we will add Testcontainers dependencies to our maven pom.xml file.

  <dependency>
     <groupId>org.testcontainers</groupId>
     <artifactId>junit-jupiter</artifactId>
     <scope>test</scope>
  </dependency>
  <dependency>
     <groupId>org.testcontainers</groupId>
     <artifactId>postgresql</artifactId>
     <scope>test</scope>
  </dependency>

After adding these dependencies here is an example test code.

Here is a breakdown of what is happening in the code:

1. @Testcontainers tells JUnit to manage Testcontainers lifecycles.
2. @Container marks a field as a container that Testcontainers should manage
3. We specify the Docker image postgres:17 and some default credentials (though Testcontainers can generate them).
4. The configureProperties method, annotated with @DynamicPropertySource, is the bridge. It takes the dynamic JDBC url, username, and password from the postgresContainer (once it’s running) and sets the corresponding spring.datasource.* properties. Spring Boot then uses these properties to configure its DataSource.
5. @SpringBootTest loads your application context, now configured to talk to the Testcontainer!

When to Use Testcontainers

Perfect for:

• Database-specific feature testing (stored procedures, custom types etc.)
• Multi service integration scenarios
• Testing database migrations and schema changes
• Validating external service integrations
• End-to-end workflow testing

Consider alternatives when:

• You need extremely fast test execution (use unit tests)
• Testing simple CRUD operations (in-memory databases might suffice)
• Resource constraints prevent Docker usage

Conclusion

In the past, integration testing was often difficult. Test environments could break easily, and developers might have to share a single database. This created many issues, especially the famous “it works on my machine” problem, where code works for one person but fails for others.

Testcontainers offers a practical and powerful solution to these old problems. It lets you control the services your application needs (like databases or message queues) directly from your test code. This gives you much better control and ensures that your tests are consistent and run the same way every time.

The result is a testing process that is more trustworthy and easier to manage for both individual developers and automated CI/CD pipelines. By using Testcontainers in your integration tests, you can be confident that your tests use the same kind of services as your production environment, which means you can trust your code to work correctly after deployment.

Resources:

• Full example repository
• Testcontainers Official Documentation
• Spring Boot Testing Best Practices

Integration Tests with Testcontainers was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

What Is the Strangler Fig Pattern?

The Strangler Fig Pattern is a strategy for gradually replacing legacy systems without a complete rewrite or big-bang release.
The idea comes from nature — specifically from how strangler fig trees grow around a host tree.
Over time, the fig replaces the host completely, but the process is slow, controlled, and safe.

In software, it means:
- You keep your legacy system running.
- You build new services or modules that handle small pieces of functionality.
- You route traffic to the new service while keeping old endpoints alive.
- Gradually, you “strangle” the legacy system until it’s no longer needed.

This approach is ideal when:
- The legacy system is too complex to rewrite from scratch.
- You need to avoid downtime.
- You want to release improvements incrementally.

How It is Used

In one of our internal projects, the login system was old — users could only log in with email + password.
The business team wanted to support GSM (phone number) login with OTP (one-time password).

At first, I considered refactoring the existing code. But the old system was deeply coupled; even a small change risked breaking authentication for thousands of users.
That’s when I decided to apply the Strangler Fig Pattern — build the new GSM login flow side by side with the old email flow, and gradually transition users.

Step 1: The Legacy Login Flow

Here’s how the old system worked:

public class LegacyAuthService {
    public TokenResponse login(String email, String password) {
        User user = userRepository.findByEmail(email)
            .orElseThrow(() - > new UnauthorizedException("User not found"));
        if (!PasswordHasher.matches(password, user.getPasswordHash())) {
            throw new UnauthorizedException("Invalid password");
        }
        return tokenService.generateToken(user);
    }
}

Step 2: Introducing a Facade Layer

To start migrating, I created an Auth Facade Controller.
It acted as a single entry point for all login requests — internally deciding whether to use the legacy service or the new one.

@RestController
@RequestMapping("/api/auth")
@RequiredArgsConstructor
public class AuthFacadeController {
    private final LegacyAuthClient legacyAuthClient;
    private final NewAuthService newAuthService;
    private final FeatureToggleService featureToggle;
   
    @PostMapping("/login")
    public ResponseEntity < TokenResponse > login(@RequestBody LoginRequest request) {
        if (featureToggle.isEnabled("use-gsm-login") && request.isPhoneLogin()) {
            return ResponseEntity.ok(newAuthService.loginWithPhone(request));
        }
        return ResponseEntity.ok(legacyAuthClient.loginWithEmail(request));
    }
}

This way, the client application didn’t need to know about the change.
It always called /api/auth/login, and the backend decided which system to use.

Step 3: Building the New GSM Login Service

Then, I created a Spring Boot microservice for the new login logic — fully independent from the legacy monolith.

@Service
@RequiredArgsConstructor
public class NewAuthService {

    private final UserRepository repository;
    private final OtpService otpService;
    private final TokenService tokenService;

    public TokenResponse loginWithPhone(LoginRequest request) {
        if (!otpService.verifyOtp(request.phone(), request.otpCode())) {
            throw new UnauthorizedException("Invalid OTP");
        }

        User user = repository.findByPhone(request.phone())
            .orElseThrow(() - > new UnauthorizedException("User not found"));

        return tokenService.generateToken(user);
    }
}

Step 4: Supporting Both Systems Together

The facade decided which system handled the login based on the request:

public class LoginRequest {
    private String email;
    private String password;
    private String phone;
    private String otpCode;

    public boolean isPhoneLogin() {
        return phone != null && otpCode != null;
    }
}

This hybrid approach allowed me to:

• Keep existing users logging in with email.
• Let new users register and log in via phone number.
• Measure how many users switched before fully migrating.

Step 5: Gradual Transition

Once the GSM login became stable, we enabled it for more users:

1. New signups required a phone number.
2. Email logins were still supported but marked for deprecation.
3. After 6 weeks, we flipped the feature toggle — all logins now went to the new service.

Monitoring and metrics helped ensure no spikes in login failures occurred. Eventually, the old flow received zero traffic, and we could safely remove it.

Step 6: Cleaning Up

Finally, we removed:

• Old /login/email endpoints.
• Password hashing utilities.
• Legacy authentication configs.

The codebase got smaller, cleaner, and easier to maintain.

Visual Overview

Here’s a simple flow diagram to show how traffic was routed during the migration:

At first, most requests went to the legacy branch.
Over time, as users adopted phone login, traffic naturally shifted to the new branch.

Key Takeaways

1. Don’t rush a full rewrite. Replace piece by piece.
2. Feature toggles are your safety net. Roll out slowly, roll back easily.
3. Monitor usage. Data should tell you when it’s safe to remove old code.
4. Keep user experience consistent. Clients shouldn’t feel the migration happening.

Final Thoughts

Migrating authentication logic is always risky — it’s the gateway to your entire system.
But with the Strangler Fig Pattern, I managed to evolve it safely, without downtime or massive rewrites.

Sometimes, the best way to modernize software is not to “burn down the old tree,”
but to let the new one grow around it — quietly, steadily, and sustainably.

The Strangler Fig Pattern in Practice: Migrating from Email Login to GSM Login in Spring Boot was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

E‑ticaret hayatımıza girdiğinden beri alışverişin doğası köklü bir biçimde değişti. E-ticaretin mobil deneyimi, sosyal medya üzerinden E-ticaret ve yapay zeka tabanlı E-ticaret ile beraber kişiselleştirilmiş deneyim derken şimdi sırada Agentic Commerce var: yalnızca öneri yapan değil, kullanıcı adına eyleme geçen yapay zekâ sistemleri.

Agentic Commerce için yaygın bir Türkçe kullanım yok, ancak bu yazıda hem kavramın ne anlama geldiğini hem de nasıl çalıştığını teknik ve pratik yönleriyle anlamaya çalışacağız.

Agentic Commerce Nedir?

Kısaca: Yapay zeka agentlarının kullanıcı adına ticari işlem yapabilmesi.

Yapay zeka, kullanıcının doğal dilde ifade ettiği niyeti anlayarak; bunu yorumlar, gerekli API çağrılarını ve veri analizlerini zincirleme biçimde yürütür, ardından işlem motorları aracılığıyla ticari aksiyonları otomatik olarak gerçekleştirir.

Yani klasik öneri yapan yapay zekanın ötesinde, sistem artık sadece öneri yapmakla kalmayıp eyleme de geçen bir modele dönüşür. Onlarca sekme açmak, fiyat karşılaştırmak ve kullanıcı yorumlarına gömülmek, bilgilerini girip ödemeye ilerlemek yerine günümüzde sadece şunu demen yeterli;

“Eşim için sade ama kaliteli bir sevgililer günü hediyesi bul.”

Teknik Bakış ve Zorluklar

Bu model, kendine özgü bazı teknik ve operasyonel zorlukları da beraberinde getiriyor.

• Ürün Kataloğu ve Stok

Üye işyerlerinin yapay zeka üzerinden satış yapabilmeleri için öncelikle ellerinde bulunan ürün id’sini, ürün başlığını, ürün açıklamalarını, fiyat ve stok bilgilerini, görsellerini ve kargo seçeneklerini uygun formatlarda (TSV, CSV, XML, JSON gibi) ve düzenli bir şekilde güncelleyerek platform sağlayıcısına iletmeleri gerekmektedir. Yapılacak satışın sıklığına göre bu bilgilerin sık sık (genellikle 15 dakikada bir) güncellenmesi gerekecektir.

• Kargo

Üye işyerlerinin seçtiği kargo seçeneğinin ve bu kargo seçeneğine göre çıkacak fiyatı yapay zeka tarafına iletmesi bir sonraki adım olan ödeme adımı için önemli bir veri olacaktır. Buradaki en büyük zorluk, seçilecek adres bilgisine göre dinamik olarak değişen yapıda bir kargo ücretinin varlığıyla alakalıdır.

Aynı zamanda, çift yönlü API iletişimiyle üye işyeri kargo sürecini otomatik olarak başlatmalıdır. Aksi halde ödeme alınmış, siparişe dönüşmüş ancak kargo süreci başlamamış olacaktır.

• Ödeme

Üye işyerleri yapay zeka tarafında hali hazırda ön tanımlı olan ödeme sağlayıcılar üzerinden işlem gerçekleştirebilir. Burada “shared payment token” kavramı ortaya çıkar. Çünkü bir yapay zeka agentının üye işyeri adına finansal bir işlem gerçekleştirebilmesi izne bağlı olmalıdır. Çünkü teorik olarak finansal işlem doğrudan üye işyeri tarafından başlatılmaz. Üye işyeri bazı kimlik bilgilerini (API key gibi) yapay zeka ile paylaşmalı ve yapay zekayı finansal işlem yapabilmek üzerine yetkilendirmelidir.

Eğer ön tanımlı bir ödeme sağlayıcı yoksa, yapay zeka ile bir entegrasyon yapılmalı, güvenli ve gerçek zamanlı, iki taraflı API iletişim ortamı kurulmalıdır.

• İade

İade akışının nereden başlayıp nereden bittiği de teknik bir tartışma konusudur. Sipariş yapay zekadan başlar ancak E-ticaret firmasında son bulur. Ancak teorik olarak iade her iki kanaldan da tetiklenebilir. Bu sebeple, iade başlatıldığında hangi kanaldan başlatılırsa başlatılsın API seviyesindeki iletişim ile beraber veri eşleşmesini kritik bir konu haline getirecektir.

Ayrıca yine iadenin kendisinin hangi ödemeye ait iade olduğu da yine bir veri eşleşmesi konusu olacaktır.

Global Örnekler

Bu alanda öncü adımlar hızla atılıyor:

• OpenAI x Shopify(Mayıs’25) & Etsy(Eylül’25)
  ChatGPT kullanıcıları artık sohbet içinde bir ürün aramak istediğinde doğrudan Shopify ya da Etsy mağazalarındaki ürünleri görebiliyor. Arka planda, OpenAI API’si Shopify’ın kataloglarını sorgulayıp sonuçları doğal dilde sunuyor ve ardından ödeme formuna yönlendirip istenilen ödeme yöntemiyle siparişi tamamlıyor.
• Gemini x PayPal (Eylül’25)
  Gemini kullanıcıları artık sohbet içinde bir ürün arayıp satın almak istediğinde, eğer ürünün satıldığı e-ticaret sitesinde PayPal geçerliyse, bu ürünü doğrudan satın alabiliyor.

Geleceğe Dair Sorular

Agentic commerce sadece ticareti değil, “karar verme” kavramını da dönüştürüyor. Peki gelecekte ne olabilir soruları ise aklımızda şimdiden yer edinmeye başladı…

• Bireysel yapay zeka asistanları müşteriler için yine yapay zeka agentları üzerinden alışveriş yapabilecek mi?
• Markalar insanlara mı, yoksa onların dijital temsilcilerine mi satış yapacak?
• “Tüketici” kim olacak — biz mi, yoksa bizim adımıza karar veren yazılım mı?
• Nesnelerin yapay zeka asistanları olabilir mi ve o nesneler, yapay zeka yardımı ile sipariş verebilir mi?

Henüz Erken, Ama Yön Belli

Bugün agentic commerce hala erken aşamada. Ancak yapay zekaların bizim adımıza düşünmeye, seçmeye ve hareket etmeye başlaması sadece ticareti değil; pazarlamayı, tasarımı, güven sistemlerini, veri gizliliğini ve etiği de kökten dönüştürecek.

E-ticaret devriminin aksine, bu kez dönüşümün merkezinde “websitesi” değil, “etkileşim” var ve belki de çok yakında, en iyi satış temsilciniz bir insan değil, sizinle yıllardır konuşan kişisel yapay zeka ajanınız olacak.

Agentic Commerce Üzerine was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello! When discussing technologies that simplify database operations in the software world, there’s a trio we often hear about: Spring Boot, JPA, and Hibernate. The combination of these three is the key to simplifying and accelerating database interactions in modern Java applications. Let’s dive into each part of this powerful combination, explore why they are so effective, and understand how they work in more detail.

What is JPA ?

The Java Persistence API (JPA) defines a standard for managing persistence between objects and relational databases in Java applications. JPA itself is not a tool or framework; rather, it is a specification consisting of a set of interfaces and rules. In essence, JPA says, “ I tell you what to do not how to do it.”

The Key Features and Purpose of JPA

Standardization and Portability

One of JPA’s biggest advantages is ensuring that different ORM implementations (such as Hibernate, EclipseLink, or OpenJPA) adhere to a standard. This means that if you ever want to switch your persistence layer to a different JPA provider, you only need to make minimal changes to your code. This adds portability to your application.

Entity Concept

The main structure of JPA is the representation of database tables as Java classes. By marking a Java class with the @Entity annotation, it becomes a JPA entity.

Mapping with Annotations and XML

JPA provides a set of standard annotations (e.g., @Table, @Column, @Id, @GeneratedValue, @OneToMany, @ManyToOne) to define how the fields of your entity classes map to the columns of database tables. Alternatively, you can also define these mappings in an XML file like orm.xml. However, annotations are much more common and practical in modern development.

EntityManager Interface

The EntityManager interface is the central API of JPA, used to interact with the database. It includes methods for basic CRUD operations and querying, such as persist() (save), find() (find by ID), merge() (update), remove() (delete), and createQuery() (create queries). The EntityManager instance is associated with a "persistence context," which tracks the entities being managed at any given time.

JPQL (Java Persistence Query Language)

JPQL is an object-oriented query language similar to SQL but operates on entity classes and fields instead of database tables and columns. It allows you to write database-independent queries. Example:SELECT s FROM Student s WHERE s.lastName = 'Smith'.

What is Hibernate?

Hibernate is the most popular and mature ORM (Object-Relational Mapping) framework that implements the JPA specification. It means Hibernate is the concrete tool that follows the rules and interfaces defined by JPA to perform actual database operations.

What Hibernate Offers and Its Working Principles:

JPA Implementation and Beyond

Hibernate fully supports JPA standards and even provides additional features and optimizations that JPA does not cover. For instance, its custom Session API (similar to JPA’s EntityManager) offers more detailed control and performance configurations.

SQL Generation and Data Transformation

Hibernate’s core task is to automatically convert the operations you perform on Java objects (e.g., save, update) into appropriate SQL queries for the underlying database and map the query results back into Java objects. This eliminates the need for developers to write SQL directly.

Database Dialects

Hibernate uses “dialect” classes to manage differences in SQL syntax and data types across various databases. This allows Hibernate to generate database-specific SQL queries from your Java entities.

Below are examples of a simple User Java entity class with only an id field, and the corresponding CREATE TABLE queries generated using org.hibernate.dialect.PostgreSQLDialect and org.hibernate.dialect.OracleDialect.

This class represents the users table in the database.

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;
}

• PostgreSQL Dialect: PostgreSQL usesBIGINT data type and theIDENTITY column property for auto-incrementing id fields.

CREATE TABLE users (
     id BIGINT GENERATED BY DEFAULT AS IDENTITY NOT NULL,
     PRIMARY KEY (id)
 );

• Oracle Dialect: Oracle uses the NUMBER data type and the IDENTITY column property for auto-incrementing id fields.

CREATE TABLE users (
    id NUMBER(19,0) GENERATED BY DEFAULT AS IDENTITY NOT NULL,
    PRIMARY KEY (id)
);

These examples demonstrate how the same simple Java entity is translated into different SQL CREATE TABLE statements through different database dialects.

Database Schema Management (DDL Generation)

Using the hibernate.hbm2ddl.auto property, Hibernate can automatically create, update, or validate the database schema at application startup (values: create, create-drop, update, validate). This is particularly useful in development and testing environments. These settings should not be used in a live (production) environment. create, create-drop, and even update modes pose significant risks for production:

• create: This option deletes and recreates your entire database every time the application starts. In production, this means irreversible data loss. All your critical data simply vanishes.
• create-drop: Like create, it creates the database at startup, but also deletes it when the application stops. If accidentally used in production, it carries the same catastrophic data loss risk as create.
• update: This mode attempts to update the existing schema. While seemingly less destructive, it can lead to unexpected data loss (e.g., when dropping columns or changing types) or compatibility issues. Losing control over your production schema sets the stage for major problems.
• validate: This mode simply validates your Hibernate configuration against the existing schema without making any changes. It's generally safe for production, but it should still be part of a broader, controlled schema management process.

Relying on hibernate.hbm2ddl.auto in production results in a critical loss of control over your database schema. Production schema changes require careful planning, versioning, and rigorous testing. Automated operations completely bypass this controlled workflow, inviting unforeseen errors and system downtime. Automatically generated issues are far harder to fix than those introduced through a managed process.

Caching

• First-Level Cache:
  A default, session-specific cache. If you read the same entity multiple times in a single session, the database is queried only once, and subsequent reads are served from the cache.
• Second-Level Cache:
  An optional cache operating at the SessionFactory level, shared across multiple sessions. It is used to improve the performance of frequently accessed data and requires external providers like Ehcache or Redis.

Transaction Management

Ensures the integrity of database operations. All operations within a transaction either succeed as a whole or fail entirely. Hibernate supports both JTA (Java Transaction API) and native (JDBC) transaction management.

What is Spring Boot?

Spring Boot is a framework built on top of the Spring Framework, designed to make it easy to create standalone, production-ready, Spring-based applications quickly. It operates on the principle of “convention over configuration,” allowing developers to focus on business logic instead of writing boilerplate code.

How Spring Boot Does It Combine the Trio?

Automatic Configuration

The biggest advantage of Spring Boot is its automatic configuration. When you add the spring-boot-starter-data-jpa dependency to your project, Spring Boot automatically configures several components for you:

• A DataSource: Automatically configures the database connection pool (e.g., HikariCP) using the spring.datasource settings in your application.yml.
• An EntityManagerFactory: Creates the main factory for JPA and sets Hibernate as the default provider.
• A PlatformTransactionManager: Configures the necessary component to manage database transactions.
• Makes it easy to manage Hibernate settings (e.g., hibernate.dialect, ddl-auto, show_sql, etc.) through application.yml or application.properties.

Spring Data JPA

Spring Data JPA is the key component that makes working with Hibernate and JPA incredibly simple in Spring Boot. It is an abstraction layer built on top of JPA. Developers can define repository interfaces to perform common database operations (CRUD) with minimal or no code. Spring Data JPA automatically generates queries based on method names.

import org.springframework.data.jpa.repository.JpaRepository;
import java.util.List;

// We create a JpaRepository with the Student entity and ID type Long
public interface StudentRepository extends JpaRepository<Student, Long> {
    //Spring Data JPA automatically generates the query "SELECT s FROM Student s WHERE s.lastName = :lastName" based on this method signature.
    List<Student> findByLastName(String lastName);

    // We can also define custom queries
    @Query("SELECT s FROM Student s WHERE s.firstName LIKE %:name%")
    List<Student> findStudentsByFirstNameContains(@Param("name") String name);
}

With this setup, you get basic CRUD methods like save(), findById(), findAll(), and delete() by simply extending the StudentRepository interface.

Why Is This Trio So Powerful?

The combination of these three technologies makes database operations in modern Java applications highly efficient, fast, and enjoyable:

• JPA Defines the Standard: It provides developers with flexibility and portability through a well-defined contract.
• Hibernate Implements the Standard: It brings JPA’s rules to life in a robust and optimized way, abstracting the complexity of database interactions. Hibernate also handles details like performance optimization, caching, and relationship management.
• Spring Boot Simplifies Everything: It makes the configuration and usage of JPA and Hibernate extremely simple.

This synergy has become the gold standard for developing database-driven applications in the Java ecosystem. Developers can focus on business logic instead of database details, enabling faster time-to-market for their applications.

Hopefully, this detailed explanation helps you better understand the relationship between Spring Boot, JPA, and Hibernate, and how each contributes to the ecosystem!

Feel free to explore the full source code for the application discussed in this article, or try it out yourself, by visiting the GitHub repository

Spring Boot, JPA & Hibernate: The Power of the Trio was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s fast-paced, ever-changing world of technology, one of the most critical factors for companies to achieve their goals, increase efficiency, and hit financial targets is a strong and efficient technological infrastructure. One of the most important components of this infrastructure is Application Programming Interfaces (APIs), which allow us to expose our applications to the outside world or allow end-users to interact with front-end applications.

To provide uninterrupted service to our users, whose numbers are increasing day by day, a well-designed API that is efficient, fast, reliable, and scalable is of vital importance for the success of our company. The performance of APIs not only affects customer satisfaction, but also directly affects factors such as the efficiency of business operations and the budget allocated to technology investments.

What is API Optimization ?

In a very general sense, API optimization involves various steps aimed at increasing the performance and efficiency of APIs. Examples of these steps include reducing service response times, minimizing latency between requests, and optimizing database queries.

In this article, I’ll cover this practical techniques and reliable methods to optimize your API for better performance and user experience.

1-) Defining suitable names and using appropriate HTTP Methods

API optimization is not only about performance, but also about readability, sustainability, and correct resource modeling. In this context, the use of appropriate HTTP methods and endpoint naming are the cornerstones of good API design. Here are a few key points:

• Nouns should be used instead of verbs in endpoint naming. /users, /products, /orders etc.
• A hierarchical relationship should be established between related resources, as in the following example: /users/123/orders
• The GET method should never be used to create or modify data. It should only be used to retrieve data, and the endpoint should be idempotent.
• For creating a new resource, use the POST method; for updating all fields of an existing resource, use the PUT method; and for partially updating data, use the PATCH method.

2-) Prevention of Abuse

DDoS is one of the most well-known examples of abuse. A malicious attacker can send thousands of API requests in a very short time, rapidly exhausting your application server’s thread pools, driving CPU and memory usage to critical levels, and eventually causing the server to become completely unresponsive.

However, similar consequences may also arise from entirely innocent behavior — for instance, when a legitimate customer unintentionally triggers a high volume of simultaneous requests to some of your services.

To mitigate the effects of such high-intensity usage patterns, a well-designed rate limiter implementation can be considered. By enforcing request limits — especially on services that handle complex business logic or intensive computations — you can prevent server overload and maintain system availability.

3-) Limiting Response

Limiting the contents of API response bodies and returning only the necessary data is considered a best practice. This approach not only minimizes the risk of data breaches caused by exposing unnecessary information but also reduces the amount of data that services need to process, resulting in improved performance.

However, there are exceptional cases where returning large payloads through APIs becomes inevitable. For instance, in an e-commerce application’s admin panel, sellers may want to view detailed reports of their sales for the last quarter of the year. Serving the entire dataset in a single response can severely degrade the performance of the service due to the size of the data.

In such cases, one of the most effective solutions is to paginate the data — delivering it to the user in chunks. The client then sends the same request multiple times to retrieve each subsequent block of data. Another alternative is to send the full dataset in a compressed format, such as a GZIP archive, rather than in raw form. This significantly reduces the size of the data being transferred and lowers bandwidth usage across the network. In the table below, you can observe the comparative differences between the three most commonly used algorithms.

4-) Caching

Caching is one of the most important techniques for improving API performance. In essence, it is based on the principle of storing frequently accessed data or computation results in memory for a specific key value, allowing it to be retrieved or computed quickly without the need for re-accessing or re-computing. Thanks to caching:

• Backend load can be minimized.
• User satisfaction is increased by reducing delays in service calls.
• System resources such as memory and network bandwidth are consumed less, contributing to system reliability.

I’d like to talk about two concepts that you may frequently encounter in caching:

Cache Hits: If the requested data is found in the cache, it is referred to as a cache hit.

Cache Miss: If the data is not found in the cache, it is termed a cache miss. In this case, as you can see in the flow diagram above, the backend server is accessed to find the desired data, and the result is added to the cache.

Caching can be widely used in various components of large-scale applications. Let’s take a look at the types of caching…

1.In-Memory Caching

This type of caching is also known as server-side caching. It is based on the fundamental principle of storing data in memory, rather than on a hard disk or a database, and accessing it from there. Since the speed of reading data from memory is much higher than from a hard disk, the performance is improved by minimizing the latency time. Products such as Redis, Memcache, and Amazon ElastiCache are very common caching implementations.

When you want to create a cache, there are a few things to keep in mind:

TTL Duration(Time To Live): This determines how long data will remain in the cache. If your data is not updated very often, you can set the TTL period to be long. However, it is important to set the TTL period to be short for data that is updated frequently. Otherwise, users may continue to see outdated data. Setting the TTL correctly according to the data’s need for updating is one of the most critical issues.

Eviction Policy: When data is stored in cache, it is typically not stored in memory indefinitely. Since memory capacity is limited, data stored here should be purged according to policies set to maintain a balance of memory load. The most commonly used policies are as follows:

• LRU (Least Recently Used): Removes the data that was used the longest time ago from the cache.
• LFU (Least Frequently Used): Removes the least frequently used data from the cache.
• FIFO (First-In, First-Out): Removes the data that was first entered into the cache

Key Design: It is particularly important to assign unique key values in caching implementations where data is stored in key-value pairs. Otherwise, there is a high probability that you will experience conflicts and data inconsistencies. An example key value will be customer:123456:order:1

2. Database Optimization

Effective database optimization plays a critical role in improving API performance. These optimizations impact not only the queries used to retrieve data but also the communication between the database and the API. Indexes are highly beneficial for accelerating data access within tables. In particular, creating single or composite indexes on columns that are frequently used in the WHERE clause is essential. However, using indexes also introduces overhead. Since each newly inserted record requires the index to be updated, this comes at a cost in terms of both storage size and CPU usage. Therefore, for tables with high insert rates, index design should be carefully planned. Over time, as the number of indexed columns increases, insert operations may experience a significant degradation in performance.

When an API accesses the database, it must first establish a connection — a process that carries its own cost. If incoming API requests increase rapidly, opening new database connections for each concurrent request can place a heavy load on the database. To mitigate this, a connection pool should be utilized. A predefined and limited number of connections are kept alive in the pool and returned to it once the task is completed. This eliminates the overhead of creating a new connection for each request. Properly configuring the connection pool — including the maximum number of connections and the idle timeout — is crucial. If the number of available connections is insufficient, threads may end up waiting for a connection to become available, potentially leading to application downtime.

The number of records returned by a database query should always be limited using pagination. Retrieving millions of records in a single request is highly risky — both for the database and the API layer. Additionally, selecting all columns using a wildcard (SELECT *) when it is not necessary leads to excessive memory usage and unnecessary network bandwidth consumption. Only the required fields should be explicitly included in the query results.

In high-write workloads, read performance may degrade over time. A common and effective solution to this problem is to separate read and write operations across different databases. While write operations are handled by the master database, the data is replicated — with a slight delay — to one or more read-only replicas. This ensures that read operations are isolated from write-intensive processes. However, the main drawback of this architecture is the potential for eventual consistency issues due to replication delays, especially for critical data.

3. HTTP Caching

The goal of this type of caching is to store HTML page content (such as images, URLs, CSS and JavaScript files) in the user’s browser on the first request to a web site, and then retrieve this content from the local cache on subsequent requests. In this way, both faster response time and increased user satisfaction, as well as a decrease in server bandwidth usage, can be achieved. Caching is not limited to the browser memory alone. An additional server called a Proxy Cache is located between the client and the server and works like CDN. In this case, the cached data is not only specific to the user, but can also be opened to all public users.

The HTTP Caching process is accomplished through directives in the request or response headers. Let’s take a look a simple response header:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=3600, must-revalidate
ETag: "a7c3d-5e1f-abc123"
Last-Modified: Wed, 07 Aug 2025 18:30:00 GMT
Expires: Wed, 07 Aug 2025 19:30:00 GMT

Cache-Control: In this section, we indicate whether the cached data is private or open to everyone, for how many seconds it will be valid, and whether it should be revalidated from the server after the time expires.

ETag: The name of the header is derived from the combination of words ‘entity’ and ‘tag’. It represents a unique value for the resource to be cached by the backend server. If this resource value changes at any time in the future, it indicates that the original resource has changed and the cache information needs to be flushed and refilled.

Expires: As the name suggests, this header information also specifies when the cache information will expire.

4-) Using Asynchronous Processing

One of the best practices is to complete processes that do not need to be completed in a very short time asynchronously. For example, since it is not necessary to send a post-order notification email immediately in an e-commerce application, it can be implemented asynchronously using message queue systems such as Kafka and RabbitMQ. For a solid example of asynchronous processing implementation, consider reviewing this article. The advantages of asynchronous processes can be listed as follows:

• By moving time-intensive operations to an asynchronous structure, the services that perform the main task will work more efficiently.
• Since email delivery is performed asynchronously, various delays or sudden interruptions in the email delivery service will not affect the order creation process.
• The greatest advantage of using message queues is that, in the event of an error during the operation, retry mechanisms allow for repeated attempts at specific intervals without data loss.

While asynchronous processing offers significant advantages, it also comes with challenges that, if not properly managed, can cause more harm than benefit. A few key considerations include:

• Difficulty in Error Handling: Due to the non-linear flow of code, handling errors within deeply nested asynchronous calls can become increasingly complex.
• Decreased Code Readability: As the number of nested asynchronous methods that call each other increases, code readability and maintainability can suffer significantly. This situation is commonly referred to as “Callback Hell” or the “Pyramid of Doom.”
• Resource Management: Although asynchronous processes may seem to run quietly in the background, they can significantly increase memory usage — especially when multiple asynchronous operations are initiated simultaneously — which may negatively impact the performance of the main thread. Additionally, concurrent asynchronous processes accessing the same resource (such as a database record with the same ID) can lead to race conditions and result in data inconsistencies.
• Debugging and Testing Challenges: The non-sequential nature of asynchronous code makes detecting and fixing bugs more difficult compared to synchronous implementations. Similarly, crafting and executing reliable test scenarios in such environments requires extra care and attention.
• Thread Pool Management: When implementing asynchronous calls using custom-created threads, it is often more efficient to utilize a customized thread pool mechanism. Creating a new thread for each individual process is highly resource-intensive. Instead, pre-initialized threads can be reused through pooling, thereby avoiding the overhead of thread creation and enabling more efficient utilization of system resources such as memory and CPU. However, thread pool configuration must be handled with great care. If the pool is not properly sized, issues such as thread starvation, resource contention, or even memory overflows (e.g., OutOfMemory errors) may occur. Therefore, parameters like core pool size, maximum pool size, queue capacity, and thread keep-alive time should be carefully tuned based on whether the workload is CPU-bound or I/O-bound.

5. Content Delivery Networks (CDNs)

It can be very costly for application servers to prepare and serve static content, such as URLs, HTML content, and images, for each request from an API request. This is especially true when the size of the visual content is large, in which case the bandwidth consumed by the application will increase dramatically. To address this issue, CDNs (Content Delivery Networks) have been developed.

CDNs, which operate with a distributed server cluster architecture, include a caching implementation that purges the stored data at regular intervals. When we return the addresses of large volumes of data stored on the CDN in service responses, this content will be delivered to the user making the request from the CDN server closest to them. This improves latency and ensures efficient use of our application server’s memory and network bandwidth.

Conclusion

Optimizing APIs is not merely a matter of improving speed — it is about ensuring reliability, scalability, and a seamless experience for both users and systems. From adopting proper endpoint naming conventions and safeguarding services against abuse, to limiting response payloads, implementing effective caching strategies, and leveraging asynchronous processing, each technique plays a vital role in building resilient APIs.

By approaching API optimization as an ongoing process rather than a one-time effort, organizations can reduce operational costs, enhance customer satisfaction, and create a robust technological foundation that grows with their business needs. In a world where milliseconds matter, well-optimized APIs are no longer a competitive advantage — they are a necessity.

API Optimization is Not a Dark Art: Demystifying Performance was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Developing software processes has come to value abstraction and classification. This has made it easier to adapt to the developing software world regarding understanding and use when a layered structure is established.

As you know, Maven is a tool that manages project configuration and the build process. However, most developers usually focus on the basic lifecycle phases and commands. In this article, we will cover some lesser known but advanced topics related to the Maven lifecycle that can improve the development process.

For those who are not familiar with it, I will briefly touch on the basic phases before moving on to the main topics.

Maven Lifecycle Overview

Maven has three built-in build lifecycles:

Default: Handles project compilation, testing, packaging, and deployment.
Clean: Removes all files generated by previous builds.
Site: Generates a project website.

Maven’s lifecycle stages generally build on each other. For example, if a project starts in the clean phase, the subsequent stages (validate, compile, test, package) execute in order, with each phase taking the output of the previous one and continuing the process. In short, a stage covers the previous one and completes the work done by the previous stage.

However, each stage serves a specific purpose, and the operations within a phase can be thought of as a subset of the previous ones. For example, the compile phase compiles the code as a result of the verifications made in the validation phase.

After a general introduction to these phases, how about learning some details that will speed up and make our work easier?

Skipping Tests

Sometimes you may want to skip tests. If the tests have already passed successfully and you do not want to run the tests on the same code again, skipping the tests saves time. In case the tests are taking too much time, skipping the tests temporarily can speed up the build process.

mvn clean package -DskipTests

• DskipTests: This does not run tests but still compiles the test code.

mvn clean package -Dmaven.test.skip=true

• Dmaven.test.skip=true: Skips compiling the test code.

Using Parallel Build (-T Parameter)

By default, Maven builds the project with a single thread. However, it has parallel build support to speed up the build process for large projects.

mvn clean install -T 1C

• 1C Uses as many threads as the number of CPU cores.
• 2C Uses twice as many threads as the number of cores.
• 4 Uses a fixed 4 threads.

This parameter can significantly speed up the build process in projects consisting of independent modules. Let’s take a look at the performance test graph I ran on my local computer.

Here are my computer’s CPU specifications:

• Model: Apple M2
• Total Cores: 8
• Physical Cores: 8
• Logical Cores (Threads): 8

Profiles (-P Parameter)

Many projects require different configurations for development, testing, and production environments. Profiles help manage the appropriate settings for these environments. Or maybe you want to create a jar file locally and compile it with the version that works in the dev environment. In this case, you can run the install with the profile variable and create the jar.

mvn clean install -P dev

Forcing Dependency Updates (-U Parameter)

This parameter tells Maven to always download and update dependencies. When you re-download old or broken dependencies in the local repository or if you add new dependencies to your project.

mvn clean install -U

Adjusting Log Levels

The following parameters can be used to make Maven’s output more detailed or simple.

• X: Enables debug mode.
• q: Quiet mode, shows only error messages.
• e: Shows more detailed error messages.

mvn clean install -X

mvn clean install -q

mvn clean install -e

Properties Set

This parameter is used to set a custom property to be used in the Maven configuration.

clean install -DskipTests 

It compiles by skipping tests. By the way, we have mentioned the similar test skipping issue above; I would like to express that we found it right to mention it separately because we think that tests have a special place in software development.

mvn clean install -Denv=prod

Sets a custom “env” property to “prod”. This is typically used for profile or condition-based configuration.

Offline Mode (-o Parameter)

Runs Maven without an internet connection.

mvn clean install -o

Dependency Resolution and Analysis

These commands are very useful in debugging unnecessary or faulty dependencies.

• dependency:tree: Shows the tree structure of dependencies.
• dependency:analyze: Detects unused or missing dependencies.

mvn dependency:tree

mvn dependency:analyze

Conclusion

Maven lifecycle is not just about basic phases. Using parallel build, optimizing tests, defining custom lifecycles, dependency analysis, and offline mode can make the build process more efficient. By mastering these features, you can optimize the build process and improve your development workflow.

Maven Lifecycle and Advanced Usage Parameters was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Maven?

Maven is a tool that simplifies dependency management in Java projects. It allows for the quick and easy inclusion and updating of external libraries used in a project (such as the PostgreSQL driver, MapStruct, Hibernate, and Spring). This makes it possible to manage all required libraries in a centralized manner, ensuring efficiency and consistency.

Maven utilizes an XML-based configuration file known as pom.xml to manage project setup. The POM (Project Object Model) file is used to define and manage the dependencies, plugins, and other configurations for the project. Maven follows the instructions in the pom.xml file to execute the build process. When a project requires an external library, that library is considered a dependency of the project. In Maven, these external dependencies are referred to as dependencies, and they are defined within the pom.xml file to ensure proper integration and management throughout the project lifecycle.

Maven resolves dependencies by downloading the required files from the sources specified in the repositories section, such as Maven Central or a private Nexus repository. These files are then stored in the local cache located in the .m2/repository directory. To streamline project management and configuration, Maven operates on a plugin-based structure, where each task (e.g., compiling, testing, or packaging) is executed by a specific plugin goal. With its standardized lifecycle structure and declarative configuration model, Maven not only ensures consistency across projects but also makes it possible to reuse processes efficiently.

What is Gradle?

Gradle is an open-source build automation tool that is widely used for Java, Kotlin, and Android projects. However, due to its versatile structure, it can also be utilized with other programming languages and platforms. Gradle simplifies and automates the software development process, improving efficiency by providing a flexible and customizable approach to building, testing, and deploying applications.

Gradle is a tool used for compiling projects, managing dependencies, and automating build processes. Its operation begins by reading the settings.gradle or settings.gradle.kts file to define the current project and module structures. It then loads configuration details such as dependencies, repositories, and tasks from the build.gradle or build.gradle.kts file. Gradle undergoes three main phases during the build process:

1. Initialization Phase: This phase loads the metadata for the project and tasks.
2. Configuration Phase: During this phase, the execution logic of tasks and how dependencies will be resolved are determined.
3. Execution Phase: In this final phase, the defined tasks are executed sequentially or in parallel, depending on the configuration.

To resolve dependencies, Gradle downloads the required files from the sources specified in the repositories section (such as Maven Central or Google Maven). To improve performance, Gradle utilizes the Gradle Daemon and a local cache located in the .gradle/caches directory. Additionally, Gradle’s flexible Domain-Specific Language (DSL) structure makes it easy to define custom tasks, plugins, and build processes, allowing for extensive customization and optimization.

Pre-Maven and Gradle Era (Ant and Manual Build Processes)

Before modern build tools like Maven and Gradle, Java developers had to rely on manual compilation and rudimentary automation tools to manage their projects. Early Java development involved manually invoking the javac compiler, setting up classpaths, and packaging JAR files by hand. As projects grew in complexity, these manual processes became inefficient, leading to the need for automation. This gap was initially filled by Apache Ant, which introduced XML-based build scripts but lacked proper dependency management. Over time, more advanced solutions like Maven and Gradle emerged, streamlining the build process, dependency management, and overall project structure.

1. Manual Compilation and Build Processes

In the early days of Java, projects were compiled and packaged manually. This meant:

• Compiling source code files one by one using the javac command
• Manually setting up the CLASSPATH
• Creating JAR/WAR files manually
• Managing dependencies by hand

This process was manageable for small projects, but as projects grew larger, dependency management and build processes became a nightmare.

2. Apache Ant (1999)

Ant was an XML-based build tool that introduced an automation system for Java projects.

✔ Advantages:

• Automated compilation, testing, and packaging using the build.xml file.
• Allowed execution of repetitive commands through a task-based approach.
• Eliminated the need for manually using javac and jar commands.

❌ Disadvantages:

• No built-in dependency management (You had to download and add external JAR files manually).
• XML files became harder to read and maintain as they grew larger.

As a result, advanced build tools like Maven and Gradle were developed to prevent time loss, reduce errors, and manage projects more efficiently.

Maven vs Gradle

As previously discussed, Maven and Gradle are two widely used build automation tools in Java development. Both tools are primarily designed to compile projects, execute tests, manage dependencies, and package applications. However, despite their shared objectives, there are several key differences between Maven and Gradle. These differences will be explored in detail under various headings, highlighting the unique characteristics and advantages of each tool.

1. Configuration Language and File Format

Maven:

• Maven uses an XML-based configuration file, pom.xml, which contains detailed information about the project’s configuration and dependencies.
• XML enforces the adherence to a specific format. However, this format can sometimes become complex and hinder readability.
• Maven adheres more closely to the “config-over-convention” approach, where explicit configuration is prioritized over convention.

Gradle:

• Gradle uses build.gradle or build.gradle.kts files, which are based on Groovy or Kotlin DSL (Domain Specific Language).
• Groovy or Kotlin provides a more readable and programming-based structure, making it easier to implement project-specific customizations.
• Gradle follows the “convention-over-configuration” principle, which allows you to accomplish more with less code by relying on sensible defaults.

2. Performance

Maven:

• Maven recompiles the entire project from scratch during each build process. Due to the lack of incremental build support, the build time may increase in large projects.

Gradle:

• Gradle, through its incremental build and build cache mechanisms, processes only the changed files. This significantly speeds up the build process.
• The performance advantage of Gradle is particularly noticeable in large and complex projects.

3. Dependency Management

Maven:

• Maven uses the information specified in the pom.xml file to manage dependencies.
• By default, Maven supports Maven Central. In case of dependency conflicts, the “dependency mediation” mechanism is activated.

Gradle:

• Gradle supports various repository systems, such as Maven Central, JCenter, and Ivy.
• Gradle’s syntax for defining dependencies is simpler and more readable.
• It offers a more flexible experience with advanced dependency resolution mechanisms.

4. Flexibility and Customization

Maven:

• Maven tends to be rigid, often confined to a specific structure.
• Customization in Maven requires the use of plugins, which can sometimes be complex and limited.

Gradle:

• Gradle is much more flexible due to its scripting language. It allows for detailed control over the build processes.
• By integrating Groovy or Kotlin-based code into the build process, you can develop project-specific solutions.

5. Learning Curve

Maven:

• Maven is easier to learn due to its simpler structure. The XML format is straightforward to understand as long as the specified rules are followed.

Gradle:

• Gradle can be slightly more complex due to its scripting-based nature. Initially, knowledge of Groovy or Kotlin may be required.
• However, once you learn Gradle, you will realize that it offers a much more flexible and powerful structure.

6. Community and Use Cases

Maven:

• Being an older tool, it has a large community and an extensive library of documentation.
• It is particularly widely used in enterprise Java projects.

Gradle:

• Due to its more modern structure, it is used as the default build tool in newer technologies, such as Android.
• Its community is steadily growing, and it is particularly popular among mobile developers.

Now, all of these features are summarized in the following table, which provides a detailed comparison between Maven and Gradle.

Conclusion

• Maven: It is ideal for simpler and enterprise projects. It may be more suitable for teams that prefer a traditional structure.
• Gradle: It has a more modern, flexible, and faster structure. It is particularly better suited for large projects or Android developers.

It is recommended to make a decision based on the needs of your project and the skill level of your team.

REFERENCES

1. https://maven.apache.org/what-is-maven.html
2. https://www.baeldung.com/maven-artifact
3. https://www.simplilearn.com/tutorials/gradle-tutorial/what-is-gradle
4. https://www.geeksforgeeks.org/difference-between-gradle-and-maven/
5. https://chakray.com/gradle-vs-maven-definitions-and-main-differences/
6. https://gradle.org/maven-and-gradle/
7. https://www.geeksforgeeks.org/apache-maven/
8. https://docs.gradle.org/

Maven vs Gradle was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nowadays, monitoring and managing microservices in real-time is a key requirement for stable and performant systems. Tools like Spring Boot Admin can play an important role in quickly identifying potential issues — such as high CPU usage, low disk availability, abnormal thread counts, and misconfigured log levels — in a single dashboard. For me, it also integrates easily with Microsoft Teams to send notifications whenever certain KPIs approach critical thresholds.

This article focuses on Spring Boot Admin 3.x.x, illustrating how I monitor CPU, memory, disk usage, threads, logs, and other metrics of my microservices. I’ll compare it briefly with popular solutions like Prometheus-Grafana and explain why I preferred a “less effort, more control” philosophy in my recent project.

Project Goals and Workflow

When setting up my microservices environment, my primary goal was to centrally manage all services, predict critical resource usage, and reduce reaction time. As traffic surges (e.g., campaign periods) or unexpected failures occur, I wanted to quickly detect performance bottlenecks and respond. Spring Boot Admin provided a straightforward solution, thanks to its direct integration with the Spring ecosystem.

Defining KPIs

To keep a consistent standard across all services, I set measurable goals:

1. CPU usage should stay below 90%.

• Heavy business logic under sudden load can spike CPU usage, impacting response times. Early detection prevents slowdowns or possible crashes.

2. Disk usage should not exceed 80%.

• Logs, cache files, and other data can fill up disk space. Once the disk is near capacity, read/write operations slow down, risking failures.

3. Thread count should stay under 150.

• Excessive threads consume system resources and complicate debugging in logs. High thread counts might indicate deadlocks or resource leaks.

4. Anticipating Server Uptime and Downtime

• In a dynamic microservices environment, services may frequently go up or down due to auto-scaling events, new deployments, or unforeseen crashes. Proactively monitoring these transitions is essential for maintaining system stability. By setting up clear alerts — such as “Server Up” or “Server Down” notifications — your team can quickly respond to issues, investigate the root causes, and minimize disruption. Regular health checks and readiness probes also help detect potential outages before they impact users, ensuring each microservice remains reliable under changing load conditions.

These KPIs were chosen based on past team experiences and known performance issues in similar projects.

Why Choose Spring Boot Admin?

While Prometheus-Grafana is excellent for long-term data storage and more advanced dashboards, Spring Boot Admin provided:

• Minimal Integration:
  Just add spring-boot-admin-starter-server to the monitoring server application and spring-boot-admin-starter-client to each microservice.
• Immediate Metrics via Actuator:
  Actuator automatically supplies CPU, memory, thread, log, and cache metrics to SBA.
• Instant Notifications in Microsoft Teams:
  A small configuration snippet can push notifications whenever thresholds are crossed.
• Less Effort, More Control:
  Instead of creating custom scrape configs or separate alert managers, SBA works “out of the box” with the Spring environment.

Integration Steps

Below is a step-by-step guide on how I integrated Spring Boot Admin into a microservices setup. Keep in mind that there are two separate applications: one is the Admin Server, and the others are Client microservices that register themselves to this Admin Server.

1. Create a Spring Boot Admin Server

Create a new Spring Boot application (often named something like sba-admin-server) and include the following dependency in your pom.xml or build.gradle

<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-server</artifactId>
    <version>3.0.0</version>
</dependency>

Then enable the Admin Server in your main application class:

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

In application.ymlYou can configure the port, security, and internal admin endpoints. For example, to allow a basic security setup, you might do:

server:
  port: 8080
management:
  server:
    port: 8081
  endpoints:
    web:
      base-path: /management
      exposure:
        include: "*"
spring:
  security:
    user:
      name: admin
      password: admin123

This ensures only authenticated users can see the Admin UI.

2. Add the Client Starter to Each Microservice

Each microservice (e.g., order-service) needs:

<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-client</artifactId>
    <version>3.0.0</version>
</dependency>

Also, expose the necessary Actuator endpoints in application.yml:

management:
  endpoints:
    web:
      exposure:
        include: "*"
  health:
    probes:
      enabled: true

In the same file, specify the Admin Server URL so the microservice automatically registers itself:

spring:
  boot:
    admin:
      client:
        url: http://localhost:8080
        enabled: true
        auto-registration: true

3. Microsoft Teams Integration

1. Create a Webhook in Microsoft Teams:

• Go to the channel where you want to receive notifications.
• Click on “Connectors” (or “Apps”) and add an “Incoming Webhook.”
• Copy the Webhook URL.

2. Configure Spring Boot Admin to use that Webhook: In your Admin Serverapplication.yml, set:

spring:
  boot:
    admin:
      notify:
        teams:
          enabled: true
          webhook-url: "YOUR_TEAMS_WEBHOOK_URL"

@Configuration
public class NotifierConfiguration {

    @Bean
    public TeamsWebhookNotifier teamsWebhookNotifier(InstanceRepository repository,
                                                     WebClient webClient,
                                                     @Value("${teams.webhook-url}") String webhookUrl) {
        return new TeamsWebhookNotifier(repository, webClient, webhookUrl);
    }

}

@Component
public class TeamsMessageSender {

    private final Queue<String> messageQueue = new ConcurrentLinkedQueue<>();
    private final WebClient webClient;

    @Value("${teams.webhook-url}")
    private String webhookUrl;

    public TeamsMessageSender(WebClient webClient) {
        this.webClient = webClient;
    }
    public void enqueueMessage(String message) {
        messageQueue.add(message);
        System.out.println("Message queued: " + message);
    }

    @Scheduled(fixedRate = 250)
    public void processQueue() {
        String message = messageQueue.poll();
        if (message != null) {
            sendToTeams(message);
        }
    }

    private void sendToTeams(String message) {
        webClient.post()
                .uri(webhookUrl)
                .header(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
                .header(HttpHeaders.ACCEPT, MediaType.APPLICATION_JSON_VALUE)
                .bodyValue(message)
                .retrieve()
                .bodyToMono(Void.class)
                .doOnSuccess(v -> System.out.println("Message sent successfully: " + message))
                .doOnError(error -> {
                    System.out.println("Message delivery failed, re-queuing: " + error.getMessage());
                    enqueueMessage(message);
                })
                .subscribe();
    }
}

3. Trigger Threshold-based Notifications (optional):

• You can leverage the Actuator’s health checks or custom metrics to send alerts. If CPU usage crosses 90% or thread count goes beyond 150, you can configure SBA to push a notification to Teams.
• Keep in mind that Teams webhooks allow a maximum of 4 notifications per second. If your system can exceed this rate, consider buffering or queueing alerts.

That’s all it takes to get instant notifications when your thresholds are breached!

Identifying and Solving Problems

1. CPU and Memory Monitoring

Spring Boot Admin’s Metrics tab shows real-time CPU and memory usage. If the CPU nears 90% or memory spikes, you’ll receive a “CPU usage is critical!” or “Memory usage is high!” notification in Teams. This early warning allows you to scale out your service or optimize resource-heavy operations before major slowdowns occur.

2. Disk and Cache Status

A near-full disk can lead to slow I/O and application crashes. SBA’s interface highlights disk usage, and you’ll get alerts when it exceeds 80%. This is crucial for implementing log rotation or cache eviction before space runs out.

3. Server Availability and Thread Management

If a microservice goes down, a “Service Down!” message will appear in Teams immediately. For thread management, SBA helps monitor if you exceed 150 threads. In that case, you might enable DEBUG logs (temporarily!) to see what’s spawning so many threads — before it leads to a crash or hidden deadlock.

4. Log Levels

Keeping logs at DEBUG all the time not only fills up your disk faster, but also makes it harder to efficiently trace errors. The excessive debug logs often bury critical failure messages, complicating troubleshooting. It’s best to enable DEBUG only for targeted debugging sessions and revert to INFO or WARN for normal operation.

Alternative Tools: Why I Chose Spring Boot Admin

While Prometheus-Grafana excels in long-term metrics storage and custom dashboards, Spring Boot Admin offered a tighter, simpler integration for my specific needs:

• Configuration:
  Prometheus requires scrape configs, Grafana needs data sources and alert rules. By contrast, SBA auto-discovers Actuator metrics from each microservice.
• Alerts in Microsoft Teams:
  SBA supports out-of-the-box Teams notifications with minimal YAML. Meanwhile, Grafana Alerts or Alertmanager require additional setups.
• Ready Features:
  Environment details, metrics, threads, and loggers are immediately visible, without extra instrumentation code.

Security Considerations

For real-world deployments, it’s important to secure the Admin UI and hide sensitive properties. At minimum, configure basic authentication on the Admin Server. In more advanced setups, you might integrate with OAuth2 or single sign-on solutions. Also be mindful of management endpoints — not all should be publicly exposed in production.

Conclusion

In this article, I demonstrated how Spring Boot Admin 3.x.x can significantly simplify real-time monitoring in a microservices-based project. By setting tangible KPIs — like keeping CPU below 90%, disk usage under 80%, and thread counts below 150 — you can proactively detect and address bottlenecks before they become outages.

Compared to tools like Prometheus-Grafana, Spring Boot Admin offers a fast path to “less effort, more control,” thanks to deep Spring integration and built-in environment, metrics, thread, and log features. The easy Microsoft Teams integration further empowers teams to respond swiftly to any anomaly.

Less Effort, More Control: Real-Time Microservice Monitoring with Spring Boot Admin 3 & Microsoft… was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

In distributed systems, ensuring reliable communication between services is essential for maintaining data consistency and integrity. The Outbox Pattern is an architectural solution to this problem, providing a way to reliably send messages while preserving the transactional integrity of your system. In this article, I will explain the best practices to follow when implementing the Outbox Pattern to maximize its reliability and performance.

Content

• What is the Outbox Pattern?
• Best Practices for Implementing the Outbox Pattern

o Transactional Integrity

o Implement Idempotent Event Processing

o Optimize the Outbox Table Design

o Reliable Event Publishing

o Event Acknowledgment and Cleanup

o Scaling

o Security

• When NOT to Use the Outbox Pattern
• Disadvantages of the Outbox Pattern

What is the Outbox Pattern?

The Outbox Pattern is an architectural design pattern used in distributed systems to ensure reliable messaging between different components or services, especially in scenarios where consistency and data integrity are critical. It involves storing events or messages in an “outbox” table within the database. Once a business operation is committed, the events are stored in the outbox table as part of the same transaction, ensuring reliability. A separate process later reads these events and sends them to external systems, such as message brokers or other services.

This approach ensures that messages are never lost or duplicated and that the system remains consistent, even in the event of failures.

Best Practices for Implementing the Outbox Pattern

1. Transactional Integrity

Single Transaction for Outbox Event: Ensure that both the business operation and the creation of the outbox event happen within the same transaction. This guarantees that the database transaction and message creation are atomic, meaning either both succeed or fail together.

Example:

2. Implement Idempotent Event Processing

Idempotent Event Handlers: The event processor should be idempotent. This means that even if an event is processed multiple times, the system should not cause unexpected side effects.

Prevent Event Duplication: Track processed events using unique event reference IDs and status fields in the outbox table. Mark the event's status as “processed/sent” only after they’ve been successfully sent to the message broker.

3. Optimize the Outbox Table Design

Dedicated Outbox Table: Use a separate outbox table to store events. This keeps business data isolated and makes it easier to manage events asynchronously.

Columns:

event_id: Unique identifier for the event.

event_type: The type of event

payload: The event data (usually in JSON format).

event_status: A flag indicating whether the event is pending, processed, or failed.

event_created_at: Timestamp of when the event was created.

4. Reliable Event Publishing

Use Reliable Messaging Systems: Once the event is created in the outbox table, it should be reliably published to a message broker (RabbitMQ, Kafka, AWS SNS/SQS). The event processor should handle retries and ensure the successful delivery of events.

Retry Logic: Implement retry logic to ensure events are eventually delivered to the message broker.

Dead-letter Queue: For events that cannot be processed after several retries, use a dead-letter queue to isolate and handle failures.

5. Event Acknowledgment and Cleanup

Event Acknowledgment: Ensure that after an event is successfully published, it is marked as processed in the outbox table.

Data Retention: Regularly clean up the outbox table after events are successfully processed to prevent the database from becoming large amounts of data. If we need to archive old events, we can store another history table.

6. Scaling

Parallel Processing: For systems with high event volumes, you can process the Outbox table in parallel by splitting the workload across multiple processors. Use locking mechanisms to claim batches of messages, allowing multiple processors to operate concurrently without conflict.

Example: Using SKIP LOCKED in SQL for Parallel Processing

FOR UPDATE SKIP LOCKED: This locks rows without blocking other transactions. If one processor locks a batch of rows, others will skip those rows and work on the next available batch.

LIMIT 100: Controls batch size, fetching 100 messages at a time.

Batch Processing:

Processing a single event at a time can become a bottleneck. Batch processing helps by reducing the number of transactions and improving efficiency.

Instead of processing one message at a time, you can process multiple messages in a single transaction.

Advantages: Fewer database round-trips and reduced I/O operations.

Batch Size Configuration: Tune the batch size based on the available memory and database performance.

Adjust Processing Frequency:

If your Outbox processor runs on a scheduled job, you can adjust the interval to process events more frequently.

Scaling Tip: Deploy multiple instances of your Outbox processor to scale horizontally. Ensure each instance locks and processes different batches.

Combining Strategies for Maximum Performance

For high-throughput systems, combining these strategies provides the best results:

· Parallel Processing + Locking (SKIP LOCKED) for concurrency.

· Batch Processing to minimize database operations.

· High-Frequency Scheduling to reduce latency and ensure near-real-time processing.

7. Security and Compliance

Encrypt Sensitive Data: If the event payload contains sensitive information, consider encrypting the data before storing it in the outbox table.

Auditability: Maintain detailed logs of all events for auditing and compliance purposes. This allows you to trace the flow of data through the system, which is important for troubleshooting and regulative requirements.

8. Monitor and Log Event Processing

Event Monitoring: Use monitoring tools to observe the flow of event processing in real time. This helps identify problems like failed deliveries or delays, ensuring you can act quickly to maintain system reliability.
Example Tools: Prometheus, Grafana, or AWS CloudWatch.

Logging and Alerts: Implement detailed logging and alerting for failures in event processing. This ensures that you can take timely action when events are stuck or the processing is delayed.

Tip: Use structured logging to make it easier to analyze logs and correlate them with specific events or issues

When NOT to Use the Outbox Pattern

While the Outbox Pattern is effective for ensuring consistency between the database and message broker, there are situations where it may not be the best choice:

1. Real-Time Requirements

The Outbox Pattern introduces delays because events are processed in batches. If your system requires real-time, low-latency event processing, direct publishing to the message broker might be better.

Example: A stock trading system where delays of milliseconds can cause significant losses.

2. Simple Systems with Low Volume

For small-scale applications or low message throughput, the complexity of implementing an Outbox Pattern might outweigh its benefits.

Example: A simple e-commerce site with low traffic that doesn’t require complex messaging guarantees.

Disadvantages of the Outbox Pattern

1. Increased Complexity

The pattern requires additional infrastructure, like an Outbox table, background job, and scheduling mechanisms. Ensuring message deduplication and reliable delivery adds to the system’s complexity.

Solution: Use a framework or library to abstract these complexities where possible

2. Higher Database Load

Storing and querying events in the same database can lead to increased I/O and locking contention, especially with high-frequency writes. This can degrade the performance of core business operations.

Solution: Archive or purge old events from the Outbox table regularly.

3. Delayed Event Propagation

Event processing is not immediate; depending on the scheduling frequency of the Outbox processor, there may be delays in delivering events.

Solution: Adjust the processing interval and batch size to balance throughput and latency.

4. Potential for Partial Failures

If the Outbox processor fails after marking some events as processed but before publishing them, you risk data inconsistency or missed messages.

Solution: Use idempotent consumers and implement a retry mechanism for failed events.

5. Requires Monitoring and Error Handling

The Outbox Processor can become a single point of failure if not monitored properly. Misconfigurations or bugs can lead to missed or duplicated events.

Solution: Implement monitoring, alerting, and retry mechanisms to ensure reliability.

6. Schema Changes Can Be Challenging

Adding or modifying fields in the event payload schema can introduce compatibility issues across services.

Solution: Use versioned event schemas (e.g. JSON Schema) and evolve the schema carefully.

Conclusion

The Outbox Pattern is a powerful tool for ensuring reliable messaging and data consistency in distributed systems. By following best practices such as ensuring transactional integrity, implementing idempotent event processing, and optimizing the outbox table, you can build robust, scalable, and fault-tolerant systems. Whether you’re building a microservices architecture or integrating multiple systems, the Outbox Pattern can help you maintain consistency while minimizing the risk of message loss or duplication.

By adopting these best practices, you can leverage the full potential of the Outbox Pattern to create reliable, maintainable, and performant distributed systems.

🔗 You can explore the full implementation of this concept in my Outbox Event Sample GitHub repository.
It demonstrates a clean and modular approach to the Outbox Pattern using Spring Boot, RabbitMQ, PostgreSQL, and JPA. The project includes publisher and consumer setups, database schema, and transaction-safe message handling.

References

Implementing the Outbox Pattern

https://microservices.io/patterns/data/transactional-outbox.html

Outbox Pattern Best Practices for Reliable Messaging in Distributed Systems was originally published in iyzico.engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.