[Backend] Implement Notification Rate Limiting

[Abd-Standard]

Description

Prevent abuse and accidental overload by introducing notification rate limiting controls.

Tasks
Define rate limit policies.
Add middleware protection.
Store rate limit metrics.
Return informative errors.

Acceptance Criteria
Excessive requests are blocked.
Limits are configurable.
Error responses are descriptive.

[Sparexonzy95]

Hi Abd-Standard,

I’d like to take on this issue. I understand the core problem: the notification backend can be abused or accidentally overloaded if clients, integrations, or automated jobs send too many requests in a short period. For a notification system, this is especially important because excessive traffic can affect delivery reliability, inflate storage/processing load, and make it harder to distinguish legitimate activity from abusive or misconfigured clients.

My approach would be to implement and/or harden notification rate limiting at the backend API layer with configurable policies, clear enforcement, metrics tracking, and descriptive error responses.

I would first review the current listener/API structure and any existing rate-limit wiring, then align the implementation fully with the acceptance criteria. The solution would define rate-limit policies through configuration rather than hardcoding values, so maintainers can tune limits by environment or endpoint. I would add middleware-style protection before notification-related routes are processed, ensuring excessive requests are blocked early while valid requests continue normally.

For tracking, I would store useful rate-limit metrics such as client identifier, request count, blocked count, reset window, endpoint, and timestamps where appropriate. This would make the feature observable and easier to debug in production. When a client exceeds the limit, I would return a proper 429 response with a clear message and retry information, instead of a generic failure.

I would also cover the feature with tests to verify that normal requests pass, excessive requests are blocked, limits are configurable, metrics are recorded, and error responses are descriptive. Finally, I would document the rate-limit behavior, configuration options, and expected response format so future maintainers can adjust or extend the policy safely.

My goal would be to deliver a clean backend PR that protects Notify-Chain from abuse and accidental overload without disrupting legitimate notification traffic.

[MoscowDev]

I’d love to take this issue on. I’ve worked on production-ready applications and collaborated extensively through GitHub workflows. I’ll dig into the current setup, implement a solid and reliable fix, and deliver a well-tested PR. My focus is on clean, maintainable code and fast, dependable delivery.

[distributed-nerd]

@distributed-nerd has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

can i work on this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @distributed-nerd to this issue.

[gloskull]

Hello, I have 4 years of experience delivering solutions for projects like this, covering backend, frontend, and smart contract development. After carefully reviewing your requirements, I have a clear understanding of the task and am confident in my ability to deliver a clean, efficient, and thoroughly tested solution on time. I prioritize code quality, maintainability, and industry best practices throughout the development process.
My PR will be submitted in under 10hours.

[francisdouglas-ux]

@francisdouglas-ux has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

can you assign me this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @francisdouglas-ux to this issue.

[drips-wave]

Congratulations, @francisdouglas-ux! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @francisdouglas-ux: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[grantfox-oss]

🦊 GrantFox — @francisdouglas-ux has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #253)
2. Your PR will be reviewed by the Core-Foundry maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@francisdouglas-ux's PR #363 was approved and merged by @Abd-Standard.

🏆 @francisdouglas-ux: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (48 total points). Track your full progress on GrantFox.

👏 Great work, @francisdouglas-ux! Keep contributing to Core-Foundry.