Separate ingestion from delivery
Apache NiFi handled RSS transformation and normalization before persistence. Backend services could work with a consistent content model rather than interpreting every upstream feed.
CONTENT DISTRIBUTION · END-TO-END OWNERSHIP
PinFacts.
From a raw RSS feed to the reader’s phone. An entire content ecosystem, designed and delivered.
Conceptual illustration of the product workflow, created for this case study.
01 / RESPONSIBILITY
What I owned.
Owned the architecture and delivery across ingestion pipelines, backend services, publisher and admin portals, and the Flutter reader app.
02 / CONTEXT
The problem behind the product.
Content needed to move from external feeds and publisher submissions into a consistent, moderated reader experience. Ingestion, editorial operations, and mobile delivery had to work as one product.
03 / SYSTEM DESIGN
Connecting the pieces.
Connected Apache NiFi ingestion and normalization to MongoDB persistence, NestJS business services, Next.js publishing tools, and a Flutter application. Change Streams linked newly stored content to automated notification workflows.
- 01RSS & publishers
- 02NiFi ingestion
- 03MongoDB
- 04NestJS rules
- 05FCM & Flutter
04 / TRADE-OFFS & IMPLEMENTATION
The decisions that matter.
Let content events drive notifications
MongoDB Change Streams detected new articles. Business rules evaluated content, formed batches, and triggered Firebase Cloud Messaging notifications for the mobile experience.
Make moderation an explicit workflow
Publisher submission and admin review, approval, and rejection were modeled as role-based operations. The web portals connected editorial decisions with reader delivery.
05 / DELIVERY
From architecture to working software.
- Delivered the full path from source ingestion to mobile consumption.
- Automated content processing and notification orchestration.
- Connected publisher and administrator workflows through role-based portals.
Thinking about scale & reliability
For the next stage of scale, I would focus on feed retries, duplicate-content handling, bounded notification batches, and recovery after interrupted event processing. Each boundary needs a clear policy for what happens when work is repeated or delayed.
Want to talk through the architecture?
Let’s get into the detailsNEXT CASE STUDY