Today I intentionally broke my own system.

My Message Service writes messages and events to a local Outbox table. A background processor then delivers those events to an Audit Service.

To test failure handling, I introduced a delay during delivery and killed the containers while events were in PROCESSING.

After restart, the processor detected the stale events, reclaimed them, and processed them automatically.

Crash recovery in distributed systems isn't optional.

#microservices #backend

Subtle Outbox bug I hit.

HTTP call + DB update in one @transactional.

If the HTTP call succeeds but the commit fails -> event delivered but not marked processed.

Restart -> duplicate delivery.

Fix: call the remote service outside the transaction.

#microservices #springboot

This query changed how my processor behaves under load.

Using FOR UPDATE SKIP LOCKED in PostgreSQL allows multiple service instances to safely claim work without stepping on each other.
Each instance locks only the rows it processes, while others move on to the next available batch.

It’s a small detail, but combined with short-lived transactions it keeps lock duration predictable and prevents instances from blocking each other.

Next step is running it with multiple instances.

#microservices

Refactored a project from synchronous REST coupling to a Transactional Outbox pattern.

Before:
message-service -> HTTP -> audit-service

After:
message-service -> DB + outbox -> async processor -> audit-service

The main goal was resilience.
Now the system tolerates service outages.
If the audit service is down, the main transaction still commits, the event is persisted in the outbox table, and a background processor retries delivery until it succeeds.
Essentially, no lost events.

#spring

While refactoring a SpringBoot login endpoint, I was reminded how much impact a small API choice can have: @RequestParam vs @RequestBody with a DTO.

They communicate very different intent.
@RequestParam is great for shaping how you query data.

For actions like login, create, or publish, @RequestBody with a DTO is a better fit: it keeps sensitive data out of URLs, and makes validation easier.

As a rule of thumb: actions belong in the request body, queries belong in the URL.

#SpringBoot #REST

While working on a #SpringMVC feature, I was reminded how much clarity comes from choosing the right annotation:

@PathVariable vs @RequestParam
If the value identifies which resource you’re accessing -> @PathVariable
If the value refines how you query it -> @RequestParam

Example:
/rooms/42 -> room 42
/rooms?date=2025-01-15 -> rooms filtered by date

The code works either way, but the API tells a clearer story when the intent is right.

#Java #Spring

Issue In my SpringBoot and Angular paste-sharing project.

After deployment, paste creation worked fine, but reading failed because the client was missing the decryption context. The root cause wasn’t encryption itself, but how the client-side key material was attached to the URL.

The issue was fixed by making sure the client-side decryption data was always attached to the URL and never sent to the server.
It was a useful lesson in how zero-knowledge systems don’t fail loudly.

#java #Spring

Not sure if this will help anyone, but I spent half a day trying to solve this issue while integrating Infinispan + Hibernate second-level cache.

Unable to unmarshall 'org.hibernate.cache.internal.BasicCacheKeyImplementation'
as a marshaller is not present in the user or global SerializationContext

Docs say to use application/x-protostream and define marshallers.

But switching to application/x-java-object just worked.
No custom marshallers. No headaches. Just Java doing its things

#java