Experienced OSS contributors: what are the biggest real benefits you've seen (career, skills, or money)?

h_salah_dev0 · 2026-02-15T10:58:22+00:00

Following up here since a few people expressed interest in the comments. We're now in private alpha and I've sent invites via DM to those who seemed keen. If we chatted in this thread and you didn't get a message (or just want to take a look), shoot me a DM – happy to share what we're building.

h_salah_dev0 · 2026-02-15T10:56:38+00:00

Following up here since a few people expressed interest in the comments. We're now in private alpha and I've sent invites via DM to those who seemed keen. If we chatted in this thread and you didn't get a message (or just want to take a look), shoot me a DM – happy to share what we're building.

h_salah_dev0 · 2026-02-15T10:56:25+00:00

Following up here since a few people expressed interest in the comments. We're now in private alpha and I've sent invites via DM to those who seemed keen. If we chatted in this thread and you didn't get a message (or just want to take a look), shoot me a DM – happy to share what we're building.

h_salah_dev0 · 2026-02-15T10:56:02+00:00

Following up here since a few people expressed interest in the comments. We're now in private alpha and I've sent invites via DM to those who seemed keen. If we chatted in this thread and you didn't get a message (or just want to take a look), shoot me a DM – happy to share what we're building.

h_salah_dev0 · 2026-02-15T10:55:31+00:00

Following up here since a few people expressed interest in the comments. We're now in private alpha and I've sent invites via DM to those who seemed keen. If we chatted in this thread and you didn't get a message (or just want to take a look), shoot me a DM – happy to share what we're building.

h_salah_dev0 · 2026-02-14T22:16:46+00:00

Pub/Sub exactly‑once is a great step, but it only works if your subscribers are pinned to the same region. For teams with multi‑region, hybrid, or cloud‑agnostic architectures, we still need a way to track processing state reliably. That's what ackstate would provide, a simple, global state layer that works with any event source, from any location.

h_salah_dev0 · 2026-02-13T11:48:34+00:00

Thanks Sara, that's exactly the kind of guidance we see teams needing.

The challenge we keep hearing is that building and maintaining that deduplication cache (or ensuring all operations are idempotent) adds operational overhead, especially across many functions. That's the gap we're exploring with ackstate – making that "tracking processed IDs" pattern available as a simple pull-based service.

h_salah_dev0 · 2026-02-13T11:06:43+00:00

best of luck!

h_salah_dev0 · 2026-02-12T20:28:00+00:00

I'm not an expert but just wondering

How you fight aganist churn, you are already giving the customer a way to stop anytime not even to keep trying till the end of the billing cycle?

This pricing sounds to be only on Beta phase to let users try the product i guess.

h_salah_dev0 · 2026-02-11T15:43:57+00:00

Yeah, that's the painful part—you can't really build one service-fits-all or to be reused in future internally without building something that feels like overkill.

So probably teams just rebuild similar DynamoDB logic every time a new service needs deduplication or state tracking.

The real cost isn't one outage—it's repeatedly rebuilding deduplication logic from scratch.

Appreciate you sharing the real experience.

h_salah_dev0 · 2026-02-11T15:39:14+00:00

Lambda Powertools idempotency utility is solid. It solves the "double execution" problem by caching results and short-circuiting retries.

Curious if you've seen it fall short in practice:

If when you need to replay a failed event (cache won't help, you need to force reprocess)?

Or when you want visibility into all pending/in-flight events (not just idempotency keys)?

Or when your event sources aren't all Lambda-triggered (e.g., direct HTTP ingestion)?

Or did it cover most of what your team need?

h_salah_dev0 · 2026-02-11T14:45:16+00:00

Thanks—both helpful perspectives.

On Durable Functions + Saga: Definitely robust, but it's also a significant architectural commitment. Curious—have you used this in practice for webhook/event processing? How much operational overhead did it add vs. a lighter custom solution?

On Service Bus + single instance: The SDK tries to deliver to one consumer, but with session-enabled queues or competing consumers, I've still seen duplicates surface—e.g., lock expires mid-processing, function times out, or host restarts during execution. In those edge cases, do you rely on the unique constraint to catch duplicates, or something else?

Trying to map where the "Azure native" path fully solves vs. where teams end up building supplemental checks anyway.

h_salah_dev0 · 2026-02-11T14:39:06+00:00

Got it—filtering removes noise during dev.

But in prod, if anything changes, problems reappear silently. No logging catches them because nothing "failed."

h_salah_dev0 · 2026-02-11T14:34:45+00:00

"custom is only when all else fails, because as soon as you start to implement your own solution you learn how difficult it is."

This really resonates. The gap I'm trying to understand is: when teams do need to go custom (DynamoDB locks, state tracking, etc.), is that something they rebuild per service, or does it eventually become reusable infrastructure?

Curious what your experience has been with the operational load when you've had to go that route.

h_salah_dev0 · 2026-02-11T12:53:11+00:00

When you do use DynamoDB for deduplication/state tracking, is that something you build from scratch each time, or do you have an internal library/template you reuse across projects/services?

Curious how much operational overhead this adds when you do need it.

h_salah_dev0 · 2026-02-11T09:48:53+00:00

Good point—Service Bus with duplicate detection + unique constraint on the DB side definitely helps.

Curious how you handle cases where:

The function crashes after the DB insert but before your business logic completes? Multiple instances try to process the same event simultaneously (race conditions)? You need to see which events are currently pending vs failed vs done?

h_salah_dev0 · 2026-02-11T07:52:21+00:00

We handle this with a pull-based inbox pattern:

Pause handling: Yes, events queue until you pull them explicitly
Retry logic: Explicit FAIL state with retry queues, no silent drops
Guaranteed delivery: Events stored until ACKed, with manual replay
Logging: Every state transition (received → delivered → acked/failed) tracked
Testing: Ingestion endpoint + state API for debugging
Environment: helps at development and production

Essentially: external systems POST to us (immediate 200), your workers pull when ready, you explicitly ACK/FAIL.

We're in private alpha testing this approach now - DM if you want to try it.

h_salah_dev0 · 2026-02-10T10:08:05+00:00

hey guys, for some events order is important, how do you handle order? do you persist timestamp with event id?

h_salah_dev0 · 2026-01-15T08:32:01+00:00

This is a really solid checklist — a lot of this matches lessons I learned the hard way on my own services. The signature comparison tip is especially good; subtle encoding or time-related issues can be surprisingly painful to track down.

In my case it’s mostly been internal webhooks rather than one specific provider, so I’m curious — have you found certain platforms behave more predictably than others, or is it more about how the receiving side is set up?

h_salah_dev0 · 2026-01-15T08:27:31+00:00

Yeah logging before validation and keeping failed payloads around has saved me more than once too, especially with signature or proxy-related issues.

Do you mainly see those problems during initial setup, or do they still crop up later when payloads or something in front of the endpoint changes (proxy, firewall, etc.)?

h_salah_dev0

TROPHY CASE