[Backend] Add Notification Archiving Service

[Abd-Standard]

Description

Implement an archiving system to move old notifications out of active storage while keeping them accessible for audits.

Tasks
Create archive process.
Add retrieval endpoints.
Define retention settings.
Document archive behavior.

Acceptance Criteria
Old notifications are archived automatically.
Archived records remain accessible.
Retention settings function correctly.

[Kaybee973]

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

I can solve this issue. Please assign it to me

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

[Sparexonzy95]

Hi Abd-Standard,

I’d like to take on this issue. I understand the core problem here: notifications should not remain indefinitely in active storage because that can make the system heavier, slower to query, and harder to maintain over time. At the same time, old notifications cannot simply be deleted because they may still be required for audits, user history, compliance review, debugging, and traceability.

My solution would be to implement a proper notification archiving service that separates active notifications from historical records while keeping archived data accessible when needed. I would add a configurable retention policy, identify notifications older than the defined retention window, safely move them into archive storage, and expose retrieval endpoints so archived notifications can still be searched or reviewed.

I would approach the implementation in a careful backend-focused way:

The archive process would preserve important notification metadata such as notification ID, recipient/user reference, event type, payload, status, timestamps, and any delivery/audit fields already used by the system. The retention setting would be configurable rather than hardcoded, so maintainers can adjust how long notifications stay in active storage. I would also make sure the archive operation is safe and predictable, avoiding duplicate archive records or accidental data loss.

For the API side, I would add retrieval endpoints for archived records, with support for practical filters such as notification ID, user/recipient, date range, or event type depending on the existing project structure. I would also include tests to confirm that old notifications are archived automatically, recent notifications remain active, archived records can still be retrieved, and zero/empty archive cases behave correctly.

I would also document the archive lifecycle clearly: when a notification becomes eligible for archiving, where it is stored, how it can be retrieved, and how the retention setting should be configured.

My goal would be to deliver a clean, maintainable PR that improves storage hygiene without sacrificing auditability or historical access.

[ekwe7]

I would love to work on this issue. I have experience building production ready applications and collaborating through GitHub workflows. I'll carefully analyze the current implementation, propose a reliable solution, and submit a well-tested PR. My focus is on clean code, maintainability, and timely delivery

[ekwe7]

I would love to work on this issue. I have experience building production ready applications and collaborating through GitHub workflows. I'll carefully analyze the current implementation, propose a reliable solution, and submit a well-tested PR. My focus is on clean code, maintainability, and timely delivery

[Dami24-hub]

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

I can work on this issue,
i am very skilled developer

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

[grantfox-oss]

🦊 GrantFox — @Dami24-hub 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 #246)
2. Your PR will be reviewed by the Core-Foundry maintainers

Good luck! Track your progress on GrantFox.

[drips-wave]

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

🧑‍💻 @Dami24-hub: 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]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@Dami24-hub's PR #267 was approved and merged by @Abd-Standard.

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

👏 Great work, @Dami24-hub! Keep contributing to Core-Foundry.

[drips-wave]

This issue has been completed by @Dami24-hub as part of the Stellar Wave Program's 6th Wave 🥳

😎 @Dami24-hub: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.