✅ Phase 8 — Production Hardening & Observability

[vimal-java-dev]

✅ Phase 8 — Production Hardening & Observability

============================================

1. Project Context (Production Setup)
2. Backend: Spring Boot (Docker on VPS)
3. Frontend: GitHub Pages
4. API: https://api.vimaltech.dev
5. Database: PostgreSQL (Docker)
6. CI/CD: GitHub Actions → GHCR → VPS pull
7. Contact endpoint: POST /api/v1/contact
8. CORS configured
9. Validation + GlobalExceptionHandler implemented
10. Returning 201 Created
11. Local + Production environments are both working.

---

Next Features To Implement

• Rate limiting for public API protection
• Email notification on contact submission
• Logging + IP capture

---

• Design production-grade rate limiting (not for a hobby and joy solution)
• Add structured logging with IP + user-agent capture.
• Add email notification cleanly (SMTP or transactional service)
• Keep everything Docker-safe and CI-friendly.

[vimal-tech-dev]

Assign me.

[vimal-tech-dev]

🚀 Now We Implement Distributed Rate Limiting (Production-Grade)

---

dependency
com.bucket4j
bucket4j-core
8.6.0

dependency
com.bucket4j
bucket4j-redis
8.6.0

dependency
org.springframework.boot
spring-boot-starter-data-redis

---

Configure Redis in application-prod.yml

spring:
data:
redis:
host: redis
port: xxxx
timeout: xxxx

---

✅ SSH Into VPS First
ssh deploy@your-vps-ip

Then run:

docker logs vimaltech-contact-api | grep profile

or

docker inspect vimaltech-contact-api | grep SPRING_PROFILES_ACTIVE

or

docker exec -it vimaltech-contact-api env | grep SPRING

---

✅ Final Correct Class (Type-Safe Version)

public class RedisRateLimitFilter extends OncePerRequestFilter {
}

---

not a compilation error anymore.

Your build fails during tests, specifically:

ContactApiApplicationTests.contextLoads » IllegalState
Failed to load ApplicationContext
activeProfiles = ["test"]

🎯 Root Cause

Your filter constructor uses:

@value("${spring.data.redis.host}")
@value("${spring.data.redis.port}")

---

🔥 Solution (Best Practice)

Add this annotation to your filter:

@Profile("prod")

So it becomes:

@component
@Profile("prod")
public class RedisRateLimitFilter extends OncePerRequestFilter {
}

mvn clean install: [INFO] BUILD SUCCESS

---

What I now have:

✅ Bucket4j 8.6 integrated

✅ Redis-backed distributed buckets

✅ Filter restricted to prod profile

✅ Build passing cleanly

✅ Test environment unaffected

This is proper production hygiene.

[vimal-tech-dev]

🚀 Now We Implement Distributed Rate Limiting (Production-Grade)

dependency com.bucket4j bucket4j-core 8.6.0

dependency com.bucket4j bucket4j-redis 8.6.0

dependency org.springframework.boot spring-boot-starter-data-redis

Configure Redis in application-prod.yml

spring: data: redis: host: redis port: xxxx timeout: xxxx

✅ SSH Into VPS First ssh deploy@your-vps-ip

Then run:

docker logs vimaltech-contact-api | grep profile

or

docker inspect vimaltech-contact-api | grep SPRING_PROFILES_ACTIVE

or

docker exec -it vimaltech-contact-api env | grep SPRING

✅ Final Correct Class (Type-Safe Version)

public class RedisRateLimitFilter extends OncePerRequestFilter { }

not a compilation error anymore.

Your build fails during tests, specifically:

ContactApiApplicationTests.contextLoads » IllegalState Failed to load ApplicationContext activeProfiles = ["test"]

🎯 Root Cause

Your filter constructor uses:

@value("${spring.data.redis.host}") @value("${spring.data.redis.port}")

🔥 Solution (Best Practice)

Add this annotation to your filter:

@Profile("prod")

So it becomes:

@component @Profile("prod") public class RedisRateLimitFilter extends OncePerRequestFilter { }

mvn clean install: [INFO] BUILD SUCCESS

What I now have:

✅ Bucket4j 8.6 integrated

✅ Redis-backed distributed buckets

✅ Filter restricted to prod profile

✅ Build passing cleanly

✅ Test environment unaffected

This is proper production hygiene.

🚀 Next Step — Deploy to Production
✅ Safe To Push
On my local machine:

git add .
git commit -s -m "Add Redis distributed rate limiting (prod only)."
git push origin feature/phase-8

Let GitHub Actions build and publish the new image.

[vimal-tech-dev]

Please check PR.

[vimal-java-dev]

I checked,

---

for i in {1..12}; do
curl -X POST https://api.vimaltech.dev/api/v1/contact
-H "Content-Type: application/json"
-d '{"name":"Test","email":"test@example.com","message":"This is a valid test message."}'
done

---

1. docker compose pull
2. docker compose up -d --force-recreate
3. docker logs vimaltech-contact-api | grep profile
4. docker exec -it vimaltech-redis redis-cli keys '*'
5. docker logs vimaltech-contact-api | grep RedisRateLimitFilter

---

But there is a real production issue after I run these,

4. docker exec -it vimaltech-redis redis-cli keys '*'
5. docker logs vimaltech-contact-api | grep RedisRateLimitFilter

[vimal-tech-dev]

Good. That helps.

Since:

✅ Image is the latest

✅ prod profile active

✅ RateLimitConfig exists

❌ Still no 429

Then we stop assuming and check the actual runtime behavior.

There is now only one realistic cause left:

Your URI condition is preventing the limiter from executing.

---

if (!request.getServletPath().startsWith("/api/v1/contact")) {
filterChain.doFilter(request, response);
return;
}

[vimal-java-dev]

---

🔹 Model 1 — CI/CD pushes image to registry (recommended production -remote)

=================
docker compose pull
docker compose down
docker compose up -d
docker logs -f vimaltech-contact-api

======================

docker compose up -d --force-recreate

====================
Below is for Redis RateLimit

docker logs vimaltech-contact-api | grep profile

docker exec -it vimaltech-redis redis-cli keys '*'

docker logs vimaltech-contact-api | grep RedisRateLimitFilter

=======================================
🔹 Model 2 — VPS builds image locally
If do locallly

==========
git pull
docker compose build --no-cache
docker compose up -d
docker logs -f vimaltech-contact-api

docker inspect vimaltech-contact-api | grep Image

[vimal-java-dev]

When frequently doing a feature branch to main
and do not want to unnecessary merged

---

This branch is behind the main.

---

• git fetch origin
• git rebase origin/main
• git push --force-with-lease

This branch is up to date with main.

---

Run the above command before

• git status
• git add .
• git commit -s -m "Initated changes"
• git push origin feature

[vimal-java-dev]

{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.043601568"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.044661976"}
{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.057364015"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.10971371"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.144864933"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.186422556"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.190447971"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.248860687"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.252009553"}

---

{
"success": false,
"message": "Too many requests. Please try again later."
}
{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.265041228"}{
"success": false,
"message": "Too many requests. Please try again later."
}

[vimal-java-dev]

{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.043601568"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.044661976"} {"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.057364015"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.10971371"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.144864933"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.186422556"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.190447971"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.248860687"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.252009553"}

{ "success": false, "message": "Too many requests. Please try again later." } {"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T02:57:16.265041228"}{ "success": false, "message": "Too many requests. Please try again later." }

xargs: warning: options --max-args and --replace/-I/-i are mutually exclusive, ignoring previous --max-args value
{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:20.8634994"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:20.865122748"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:20.912235061"}
{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:20.915827622"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:20.973423806"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:21.007068901"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:21.018694466"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:21.063451079"}{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:21.082734378"}
{"success":true,"message":"Message received successfully.","timestamp":"2026-03-04T03:01:21.125387532"}

🧠 Important Understanding
Bandwidth.simple(10, Duration.ofMinutes(1))

means:
10 tokens capacity, refilled smoothly over 60 seconds.
That is:

• 10 tokens per minute
• = 1 token every 6 seconds

1. So if your requests are ~1.3 seconds apart:
2. After 6 seconds → 1 token refilled
3. After 12 seconds → 2 tokens refilled
4. So your bucket never fully empties during slow sequential testing.

---

{
"success": false,
"message": "Too many requests. Please try again later."
}
{
"success": false,
"message": "Too many requests. Please try again later."
}

I got:

• 1–10 → 201
• 11+ → 429

This sends 12 requests simultaneously.
Now you WILL see 429 without needing logging.

[vimal-java-dev]

🏁 Final State

My system now:

1. Enforces 10 requests per minute per IP
2. Works under parallel load
3. Works under sequential load
4. Correctly blocks overflow
5. Is production-ready for a single VPS
6. I have done with rate limiting.

[vimal-java-dev]

PR #30 merged and closed.