DEV Community: Jairo Junior

Hy guys, I've updated my portfolio, if you want to see it, its here: https://jairo.dev.br/

Jairo Junior — Fri, 27 Mar 2026 18:02:48 +0000

jairo.dev.br

Did you know that your app just need an umbrella, let's talk about it and the impportance of the rate-limiting in your app.

Jairo Junior — Fri, 13 Mar 2026 11:29:41 +0000

Jairo Junior

Mar 10

Rate Limiting: How to Stop Your API From Drowning in Requests

#backend #learning #cloud #sre

Comments

4 min read

Rate Limiting: How to Stop Your API From Drowning in Requests

Jairo Junior — Tue, 10 Mar 2026 18:34:04 +0000

Hello! I'm Jairo.

Your favorite dev.to writer.

Just kidding — I know I'm not. Just breaking the ice 😄

Last week I was reading an excellent book called System Design Interview by Alex Xu. If you work with backend systems and haven't read it yet, you probably should.

One concept from the book reminded me of something interesting about software engineers: we all know rate limiting exists, but very few engineers really understand when to use it, how it works internally, and which strategy to choose.

So today let's talk about one of the most important protections your API can have: rate limiting.

What Is Rate Limiting?

Let’s imagine something simple.

Your application is a person walking in the rain, and every raindrop represents an HTTP request hitting your server.

At first, everything is fine. Then the rain gets heavier. More drops. More requests. Eventually your application becomes completely soaked — CPU usage increases, your database starts struggling, and suddenly your server turns into soup.

Not ideal.

What do we do when it's raining?

We grab an umbrella.

(No, not the evil corporation from Resident Evil — a real umbrella.)

That umbrella represents a rate limiter. It doesn't stop the rain entirely; it simply controls how much rain reaches you. In the same way, a rate limiter allows some requests to pass while blocking the excess ones, protecting your system from overload.

What Happens Without Rate Limiting?

Without rate limiting, a client could send:

10 requests per second
100 requests per second
1000 requests per second

Your application will try to process every request it receives. Eventually this leads to CPU overload, database contention, cascading failures, and sometimes a full system crash.

With rate limiting in place, the server can simply respond with:

HTTP 429 - Too Many Requests

Which is basically your server saying:

"Slow down, my friend."

Common Rate Limiting Algorithms

There are several strategies used to implement rate limiting. Each one has different trade-offs depending on the system requirements.

Let's go through the most common ones.

Token Bucket

The Token Bucket algorithm is one of the most widely used rate limiting strategies.

Imagine a bucket filled with tokens. Every incoming request must take one token to be processed. If the bucket still has tokens, the request is allowed. If the bucket is empty, the request is rejected.

Tokens are added back into the bucket at a fixed rate.

Example configuration:

Bucket capacity: 10 tokens
Refill rate: 1 token per second

This allows the system to support short bursts of traffic, but once all tokens are consumed, incoming requests must wait until new tokens are added.

This algorithm is popular because it supports bursts while still controlling overall traffic.

Leaky Bucket

The Leaky Bucket algorithm works a bit differently.

Imagine a bucket with a small hole at the bottom. Requests enter the bucket like water, but water leaks out at a constant rate.

If too many requests arrive too quickly, the bucket fills up and eventually overflows, causing new requests to be rejected.

This approach forces requests to be processed at a constant and predictable rate, which helps smooth traffic spikes.

The downside is that it doesn't handle bursts as well as the token bucket strategy.

Sliding Window Log

The Sliding Window Log strategy tracks the timestamp of every request.

For example, if your limit is 5 requests per minute, the system checks all requests that happened within the last 60 seconds.

If five requests already exist in that window, the new request is rejected. If not, it is allowed.

This method is very accurate because it always considers the real time window instead of fixed intervals.

However, it requires storing many timestamps, which can become expensive at large scale.

Sliding Window Counter

The Sliding Window Counter is an optimization of the sliding window idea.

Instead of storing every timestamp, it keeps track of only two counters: requests in the current time window and requests in the previous window.

The algorithm then calculates a weighted average between those two counters to estimate the real request rate.

This method dramatically reduces memory usage while still providing good accuracy, which is why it is commonly used in large distributed systems.

Implementing Rate Limiting in Java

Now let's look at a few simple ways to implement rate limiting in Java.

These examples are simplified but illustrate the idea.

Simple In-Memory Rate Limit

import java.util.concurrent.ConcurrentHashMap;

public class SimpleRateLimiter {

    private final ConcurrentHashMap<String, Long> lastRequest = new ConcurrentHashMap<>();

    public boolean allowRequest(String clientId) {
        long now = System.currentTimeMillis();
        Long last = lastRequest.get(clientId);

        if (last == null || now - last > 1000) {
            lastRequest.put(clientId, now);
            return true;
        }

        return false;
    }
}

This example allows one request per second per client.

Token Bucket Implementation

import java.util.concurrent.atomic.AtomicInteger;

public class TokenBucket {

    private final int capacity = 10;
    private final AtomicInteger tokens = new AtomicInteger(capacity);

    public boolean allowRequest() {
        if (tokens.get() > 0) {
            tokens.decrementAndGet();
            return true;
        }
        return false;
    }

    public void refill() {
        if (tokens.get() < capacity) {
            tokens.incrementAndGet();
        }
    }
}

A scheduled task can periodically refill tokens.

Using Resilience4j (Production Approach)

In production systems, engineers often use libraries instead of building rate limiters from scratch.

One popular option is Resilience4j.

RateLimiterConfig config = RateLimiterConfig.custom()
        .limitForPeriod(5)
        .limitRefreshPeriod(Duration.ofSeconds(1))
        .timeoutDuration(Duration.ofMillis(0))
        .build();

RateLimiter rateLimiter = RateLimiter.of("apiLimiter", config);

Supplier<String> decoratedSupplier =
        RateLimiter.decorateSupplier(rateLimiter, () -> "Hello API");

Try.ofSupplier(decoratedSupplier)
        .onFailure(e -> System.out.println("Rate limit exceeded"));

This approach integrates well with Spring Boot and production APIs.

Where Rate Limiting Is Usually Applied

Rate limiting can be implemented in several layers of your architecture.

At the API Gateway, tools like NGINX, Kong, Cloudflare, or AWS API Gateway commonly enforce limits before traffic even reaches your application.

Inside the application layer, libraries like Resilience4j or Bucket4j allow developers to control request flow directly within the service.

For distributed systems, Redis is often used to share rate limit counters across multiple instances.

Final Thoughts

Rate limiting looks simple on the surface. But once your system begins handling real traffic, it quickly becomes clear how important it is.

A well-designed rate limiter protects your:

API
infrastructure
databases
users

And sometimes, the difference between a stable system and an outage is surprisingly simple.

Sometimes your API just needs…

a good umbrella ☔

Stop building a new microservice for every problem. I almost built another backend just to handle personalization logic in my workout app. Instead, I used AI as a controlled decision layer. AI doesn’t replace architecture. It becomes part of it.

Jairo Junior — Tue, 03 Mar 2026 12:14:01 +0000

Jairo Junior

Mar 3

Replacing a Rule Engine with AI: A Solo Developer Decision

#ai #backend #architecture #programming

Comments

3 min read

Replacing a Rule Engine with AI: A Solo Developer Decision

Jairo Junior — Tue, 03 Mar 2026 12:05:40 +0000

Hello! I’m Jairo Jr. 👋
I hope you’re doing great.

I’m a backend software engineer and I’m currently building an app to generate gym workouts for beginners.
And at some point, I hit a very real problem.

I needed the app to create something personalized for each user.

And that’s where things got complicated.

The problem

I started asking myself:

Should I create another backend just for personalization?
Should I build a microservice to handle user profiles and workout rules?
Should I design a full recommendation engine with categories, difficulty levels, and decision trees?

Technically, all of that is possible.

But then reality kicked in.

This is a solo project.
I already have one backend running.
Creating another service just to manage complex workout logic would mean:

more infrastructure cost
more maintenance
more mental overhead
slower development

So I stopped and asked a different question:

Do I really need to build all this logic manually?

The “backend-first” mindset (and why it didn’t make sense)

My first idea was very classic backend thinking:

collect user data (goal, level, duration)
map everything into a workout category tree
choose exercises based on rules
define sets and repetitions programmatically
store and version all of this logic

Basically, build a recommendation engine from scratch.

For a big team? Maybe.
For a solo app? Overkill.

So instead of asking how to build it, I asked:

How can AI help me make this decision — without losing control?

The savior: LangChain + OpenAI

After evaluating complexity and cost, I chose a simpler approach:

a lightweight service that calls OpenAI’s API
structured prompts
strict schema validation
controlled domain data

Instead of building a heavy rule engine, I built an AI-powered decision layer.

And yes… I used TypeScript 😅
(I’m a Java fan, but LangChain is much more mature with TS right now.)

How the AI flow works

The architecture is simple and intentional.

PromptTemplate → ChatOpenAI → StructuredOutputParser

What this means in practice:

The prompt defines the role, business rules, and output format
OpenAI generates the response
StructuredOutputParser forces the output to match a strict Zod schema

No random text.
No broken JSON.
No guessing.

What the model actually sees

The AI receives real context, not just a generic prompt:

user profile (goal, level, duration, etc.)
an explicit catalog of allowed exercises
strict rules like:
- valid exercise IDs
- required YouTube links
- ISO date format
- difficulty and category mapping

The model doesn’t invent workouts.
It chooses from a controlled domain.

That was a key decision.

Why this was cheaper than another backend

Instead of:

building complex domain logic
maintaining rule trees
evolving workout selection algorithms

I delegated the decision-making to AI.

And here’s the interesting part:

As more workouts are generated, I reuse previous context to reduce unnecessary calls to OpenAI.

So the system improves over time:

more workouts → better context
better context → fewer calls
fewer calls → lower cost

In the end, this solution was much cheaper than building and maintaining a full recommendation backend.

What I learned about prompt structure (the hard way)

This only worked because the prompt was treated like code, not text.

What worked well

Low ambiguity output
StructuredOutputParser + format instructions keep responses clean.
Domain control
Allowed exercise catalogs prevent hallucinated IDs.
Functional safety
Constraints and realistic rules are explicit in natural language.
Higher determinism
temperature: 0 makes responses more predictable.

This isn’t “ask AI and hope”.
It’s “ask AI with constraints”.

Problems I found along the way

Not everything was perfect.

Some issues I identified:

some fields were requested in the prompt but overwritten in the backend
difficulty and category were guided, but not strictly validated as enums
the prompt was too large and mixed responsibilities

AI works best with structure — and so does code.

Improvements that made a big difference

split system and user messages using ChatPromptTemplate
validate business rules in code, not only in prompts
remove redundant fields from the prompt
strengthen exercise ID validation
version the prompt (PROMPT_VERSION=v1)

AI doesn’t replace architecture.
It becomes part of it.

Final thoughts

This article isn’t about saying “AI is magic”.

It’s about realizing something important:

Sometimes you don’t need to build a massive system to solve a complex problem.

Sometimes it’s better to:

delegate the decision layer
control the input
validate the output
optimize for cost and simplicity

AI is powerful, but only when you define the boundaries.

You design the contract.
You validate the result.
AI generates the answer.

And that’s the difference between building a product and just writing prompts.

let's talk about the most silent hero of all our apps

Jairo Junior — Mon, 16 Feb 2026 16:55:11 +0000

Jairo Junior

Feb 13

Cache-Control: the silent hero in communication between applications

#cache #http #api #microservices

Comments

3 min read

Hello, it's time to know a little about the one of the most powerful cache strategies the super hyper duper, power, blast, beautiful, sorry I'm lost. LADIES AND GENTLEMEN, THE CACHE CONTROL!!!! #caching #programming #coding

Jairo Junior — Fri, 13 Feb 2026 23:10:54 +0000

Jairo Junior

Feb 13

Cache-Control: the silent hero in communication between applications

#cache #http #api #microservices

Comments

3 min read

Cache-Control: the silent hero in communication between applications

Jairo Junior — Fri, 13 Feb 2026 23:09:03 +0000

When people talk about performance, scalability, or even costs, they usually jump straight to:

bigger machines
more replicas
faster databases
more complex architectures

But there’s one HTTP detail that is almost always underestimated and, at the same time, insanely powerful:

👉 Cache-Control

If you work with communication between different apps (frontend ↔ backend, backend ↔ backend, BFFs, APIs, gateways, etc.), understanding cache-control can save you latency, money, and a lot of pain.

The problem we usually ignore

In many systems, requests look like this:

App A calls App B
App B calls App C
App C hits a database or an external API

And this happens all the time, even when:

the data barely changes
the response is identical for minutes (or hours)
thousands of users are requesting the same thing

So we end up doing:

repeated network calls
repeated serialization/deserialization
repeated DB reads

All for the same response.

That’s not just inefficient — it’s unnecessary.

Where `Cache-Control` fits in

Cache-Control is an HTTP header that tells the consumer how long a response can be reused and under which conditions.

And the beauty of it is:

✅ it’s standardized
✅ it works across different apps and languages
✅ it doesn’t require shared memory or tight coupling

You’re basically saying:

“Hey, this response is safe to reuse for X seconds.”

And suddenly, a lot of things get faster without changing your core logic.

A simple example

Imagine an API that returns configuration data:

GET /configs

The response rarely changes.

Instead of forcing every client to hit the API every time, you return:

Cache-Control: public, max-age=300

Now:

browsers can cache it
gateways can cache it
reverse proxies can cache it
other backend services can cache it

For 5 minutes, everyone can reuse the same response.

No extra code.
No extra infra.
Just a header.

Cache between backend services? Yes, please.

A common myth is:

“Cache-Control is just for browsers.”

Not true.

When you have:

microservices
BFFs
API gateways
edge services

Cache-Control becomes a contract between services.

App B doesn’t need to guess:

if it can cache
for how long
or if it should revalidate

The producer tells the truth, and the consumer follows it.

That’s clean communication.

Performance is not the only win

1. Lower latency

Cached responses are usually served in microseconds, not milliseconds.

2. Lower cost

Fewer requests:

less CPU
fewer DB hits
fewer external API calls

That shows up directly on the bill.

3. Better resilience

When downstream services are slow or unstable, cached responses can:

absorb traffic spikes
reduce pressure during incidents
keep the system usable even under partial failure

Sometimes cache is the difference between:

“the system is degraded”
and
“everything is on fire 🔥”

Cache-Control is also about correctness

Cache is not only about speed.

Headers like:

no-cache
no-store
private
must-revalidate

allow you to be explicit about what should not be cached.

That avoids:

stale sensitive data
user-specific leaks
weird bugs caused by over-caching

Good cache-control is about control, not just caching everything.

A practical rule of thumb

If an endpoint:

returns the same response for many users
doesn’t change on every request
is expensive to compute
is called frequently

👉 it probably deserves a Cache-Control header.

Even a small max-age=30 can make a noticeable difference.

Why this matters more in distributed systems

As systems grow, communication cost becomes real:

network hops
retries
timeouts
cascading failures

Cache-Control helps you reduce unnecessary conversations between services.

And in distributed systems, fewer conversations usually means:

fewer problems
simpler reasoning
better sleep at night 😄

Final thoughts

Cache-Control is not fancy.
It won’t show up in architecture diagrams.
It won’t impress in a meetup slide.

But it works.

And when you start using it intentionally, you realize something important:

Sometimes the biggest performance gains come from saying
“you don’t need to call me again… not yet.”

If you’re building APIs and not thinking about Cache-Control, you’re leaving performance and reliability on the table.

And that’s an easy win you don’t want to miss. 🚀

Hello Guys let's talk about how AI can increase your knowledge and not just making things for you ?

Jairo Junior — Wed, 11 Feb 2026 22:44:47 +0000

Jairo Junior

Feb 11

Ai Helped Me to Configure a Load Balancer in Google

#googlecloud #ai #programming #devops

Comments

3 min read

Ai Helped Me to Configure a Load Balancer in Google

Jairo Junior — Wed, 11 Feb 2026 22:43:02 +0000

Hi!

I’m Jairo, a Software Engineer at Mercado Libre.

Like every backend dev at some point, I started asking myself: “Ok… how do I actually host an app?”
Not because I wanted to become a DevOps wizard overnight (and yes, I know DevOps is way more than deploying stuff — please, DevOps friends, don’t cancel me 😅).
I just wanted to learn a bit, understand the moving parts, and stop treating infra like magic.

The problem that blocked me

I was trying to do something that sounds simple:

I have a domain, and I want a route like:

/api → Cloud Run app #1
/worker → Cloud Run app #2

For a lot of people this is easy. You’ll say:
“Bro, that’s just a Load Balancer.”

And I agreed… for about 3 seconds.

Then my brain went:

“OK COOL… HOW DO I DO THAT?”

And that question stayed stuck in my head while I clicked around GCP like a lost tourist.

I opened the GCloud dashboard, started pressing buttons, scanning menus, searching for something that looked like “routes”, “paths”, “domains”, “magic”… anything.

And then I saw it.

The most beautiful AI logo of my life.

Not even joking: that little icon saved my night.

AI didn’t just solve it — it gave me a shortcut (and that’s dangerous)

I explained what I wanted:

one domain
two routes
two different Cloud Run services
path-based routing

And in two minutes, the AI gave me Terraform code that would set everything up automatically.

That’s the moment where you can easily become a copy/paste developer.

And I’m not saying copy/paste is always bad — I do it too… but only when I understand what’s happening.

Because if you don’t understand the infra you’re deploying, you’re basically running random commands in production with a smile 😄

The real problem with “AI helping you code”

These days everyone talks about “how to use AI to code faster”.

But I think most of us are asking the wrong question.

Instead of:

“How can AI do this for me?”

The better question is:

“How can AI teach me how to do this?”

Because if AI makes a mistake (and it does), and you don’t know what the AI is doing… you’re not becoming a better engineer.

You’re becoming a professional prompter.

And that’s a very fragile career path.

The move that changed everything

So after reading the Terraform code, I told the AI something like:

“I don’t want you to do it for me.
Teach me how to do it inside Google’s platform.”

And boom.

It gave me a step-by-step explanation:

what to configure first
why each part exists
where to click
what each resource is doing
how routing actually works behind the scenes

That night I didn’t just “deploy something”.

I learned something.

And that’s the difference.

Final message

AI is amazing. It can save you hours. It can unlock you when you’re blocked.

But you need to remember:

✅ You should control the AI.
Not let the AI control you.

Use it to build faster, yes…
but also use it to learn, otherwise you’ll always depend on it.

Tell AI what you want — and make it explain the “why”.

Let's learn something about reactive programming and a way to make your application flux more SECURE ? READ BELOW AND KNOW HOW DO IT

Jairo Junior — Tue, 10 Feb 2026 00:54:22 +0000

Jairo Junior

Feb 4

Is DEFER defending your reactive app flux ?

#programming #reactiveprogramming #spring #circuitbreaker

Comments

3 min read

which is the best ai tool for devs. THAT'S MY OPINION BELOW

Jairo Junior — Tue, 10 Feb 2026 00:53:06 +0000

Jairo Junior

Feb 10

A dev coding setup in 2026

#ai #programming #productivity #performance

Comments 2

2 min read

DEV Community: Jairo Junior

Hy guys, I've updated my portfolio, if you want to see it, its here: https://jairo.dev.br/

Did you know that your app just need an umbrella, let's talk about it and the impportance of the rate-limiting in your app.

Rate Limiting: How to Stop Your API From Drowning in Requests

Rate Limiting: How to Stop Your API From Drowning in Requests

What Is Rate Limiting?

What Happens Without Rate Limiting?

Common Rate Limiting Algorithms

Token Bucket

Leaky Bucket

Sliding Window Log

Sliding Window Counter

Implementing Rate Limiting in Java

Simple In-Memory Rate Limit

Token Bucket Implementation

Using Resilience4j (Production Approach)

Where Rate Limiting Is Usually Applied

Final Thoughts

Stop building a new microservice for every problem. I almost built another backend just to handle personalization logic in my workout app. Instead, I used AI as a controlled decision layer. AI doesn’t replace architecture. It becomes part of it.

Replacing a Rule Engine with AI: A Solo Developer Decision

Replacing a Rule Engine with AI: A Solo Developer Decision

The problem

The “backend-first” mindset (and why it didn’t make sense)

The savior: LangChain + OpenAI

How the AI flow works

What the model actually sees

Why this was cheaper than another backend

What I learned about prompt structure (the hard way)

What worked well

Problems I found along the way

Improvements that made a big difference

Final thoughts

let's talk about the most silent hero of all our apps

Cache-Control: the silent hero in communication between applications

Hello, it's time to know a little about the one of the most powerful cache strategies the super hyper duper, power, blast, beautiful, sorry I'm lost. LADIES AND GENTLEMEN, THE CACHE CONTROL!!!! #caching #programming #coding

Cache-Control: the silent hero in communication between applications

Cache-Control: the silent hero in communication between applications

The problem we usually ignore

Where Cache-Control fits in

A simple example

Cache between backend services? Yes, please.

Performance is not the only win

1. Lower latency

2. Lower cost

3. Better resilience

Cache-Control is also about correctness

A practical rule of thumb

Why this matters more in distributed systems

Final thoughts

Hello Guys let's talk about how AI can increase your knowledge and not just making things for you ?

Ai Helped Me to Configure a Load Balancer in Google

Ai Helped Me to Configure a Load Balancer in Google

The problem that blocked me

AI didn’t just solve it — it gave me a shortcut (and that’s dangerous)

The real problem with “AI helping you code”

The move that changed everything

Final message

Let's learn something about reactive programming and a way to make your application flux more SECURE ? READ BELOW AND KNOW HOW DO IT

Is DEFER defending your reactive app flux ?

which is the best ai tool for devs. THAT'S MY OPINION BELOW

A dev coding setup in 2026

Where `Cache-Control` fits in