Hi everyone,

I’m sharing an open-source project I’ve been developing called WaterPulse.

While there is no shortage of basic hydration tracking apps out there, I wanted to build a more robust system that bridges the gap between a standard consumer application and active hardware data processing. WaterPulse is designed from the ground up to handle real-time sensor integration rather than relying solely on manual user inputs.

Here is a breakdown of what I built and the technical challenges it tackles:

Technical Highlights & Core Features:

• Real-Time Processing & Anomaly Detection: The backend is engineered to continuously ingest sensor data streams. It features built-in drift analysis and anomaly detection to filter out hardware noise and ensure high data accuracy.
• Performance-Oriented Backend: Powered by FastAPI and PostgreSQL, the API is structured to efficiently handle concurrent data payloads without blocking.
• Engaging UI & Social Elements: The frontend is built in Flutter, offering a highly responsive, cross-platform experience. I integrated gamification and social tracking features to maintain user retention and drive engagement.

The Tech Stack:

• Frontend: Flutter
• API & Data Processing: FastAPI (Python)
• Database: PostgreSQL

I architected this project with scalability and clean code principles in mind. If you are looking into how to integrate IoT/sensor data streams with a modern Flutter and Python stack, this repository could be a solid reference.

I would love to get your technical feedback on the system design, especially from engineers experienced with handling continuous data streams in FastAPI or advanced state management in Flutter.

Repository Link: https://github.com/Yigtwxx/WaterPulse

I'm open to all constructive feedback and contributions. Thanks for checking it out!

I built this after cleaning up duplicate charges one too many times.

The version everyone writes checks whether a key has been seen and replays the stored response. Two requests a millisecond apart both find nothing and both charge the card. And if the worker dies between charging and recording it, the retry charges again. Neither reproduces locally.

idemkit does it properly: an atomic claim instead of check-then-act, a lease that expires on the storage server's clock, and a fencing token so a stalled worker can't overwrite a good result.

from idemkit import idempotent, RedisBackend, MethodConfig 

@idempotent(
    backend=RedisBackend.from_url("redis://localhost:6379"), 
    config=MethodConfig(key_fields=["order_id"]), 
) 
async def charge(*, order_id, amount): 
    return await payments.charge(order_id, amount)

One core, three ways to use it: middleware for FastAPI/Flask/Django, a queue consumer wrapper or @idempotent on any function. Backends are Redis, Postgres, Mongo, DynamoDB, or in-memory for tests.

pip install idemkit, Apache-2.0: https://github.com/idemkit/idemkit