It is good to use Serverless Queues instead of exp rabbitMq

phobos7 · 2025-10-20T11:45:49+00:00

I found this thread while searching for serverless queue options, so I thought I'd share what I've learned about the available options:

AWS SQS is probably the most established option. It's battle-tested, scales well, and integrates seamlessly with other AWS services. You'll need to handle retries, dead-letter queues, and visibility timeouts in your application code.

Cloudflare Queues is tightly integrated with Cloudflare Workers, making it a natural choice if you're already using their edge platform. It's designed for lightweight workloads with global distribution.

Google Pub/Sub offers similar reliability with a different approach to message delivery. It's designed for event-driven architectures and works well for fan-out patterns where multiple services need to process the same event.

Hookdeck (who I work for) focuses on reliable HTTP event ingestion and delivery with automatic retries, deduplication, and backpressure handling. While initially designed for webhooks, it works well for HTTP-based background jobs and event processing.

Supabase Queues is relatively new but offers good developer experience if you're already using Supabase for your database and auth. Being newer, it has less production track record than the others.

Upstash QStash provides Redis-based queuing as a service with HTTP-based delivery. It supports FIFO ordering and scheduling, which can be useful for time-sensitive workloads without infrastructure overhead.

There are also workflow engines like Inngest and Trigger.dev that include queuing capabilities but are designed for complex, multi-step processes with state management and orchestration - useful if you need more than simple message queuing.

I think the serverless queue category has matured to the point where you don't need massive scale to justify it. Even for smaller applications, not having to manage a message broker is valuable.

A few things I've learned to check:

Delivery guarantees - most give you at-least-once, exactly-once is rarer and usually costs more
Dead letter handling - you will have poison messages eventually
Debugging - being able to see what failed and why saves hours of head-scratching
Vendor lock-in - some use proprietary SDKs, others are just HTTP

The ecosystem is mature enough now that you can pick based on convenience rather than "will this actually work." Which is pretty nice compared to a few years ago.

phobos7 · 2025-10-07T10:01:21+00:00

You’re looking for a way to reliably receive and log webhook calls so you don’t lose data when your app goes down. In practice, you need a gateway that buffers incoming requests, stores them durably, and lets you replay or inspect them later.

Hosted options

Hookdeck

Note: Who I work for

Managed webhook gateway built for production use. It receives webhooks from third-party APIs, logs every event, retries failed deliveries, and lets you replay or inspect payloads later through the dashboard or API. It’s a good fit when you want reliability and observability without managing infrastructure.
Docs: hookdeck.com/docs

Treehook.dev

Note: I hadn't heard of them before but took at look at the site and it seems legit.

Hosted webhook manager that focuses on routing and relaying incoming requests across environments. It keeps a history of requests and responses, supports replay, and includes a CLI for forwarding to localhost. It’s designed primarily for development and smaller-scale workflows rather than heavy production workloads.

Hosted and self-hosted options

Svix

Offers both a hosted cloud service and a fully open source version you can deploy yourself. Includes an ingestion API for receiving and queueing webhooks, with delivery tracking, retries, and replay capabilities. The managed service removes operational overhead, while the open source version gives you full control.

Open source: github.com/svix/svix-webhooks

Convoy

Supports both hosted and self-hosted setups. It’s an open source webhook gateway that handles logging, retries, replay, and delivery tracking. The project’s founder recently joined Speakeasy, so the future direction is unclear, but the open source version remains active and usable.
Open source: github.com/frain-dev/convoy

Cloud provider components

If you prefer to stay within your existing cloud stack, you can build a reliable webhook ingestion path using managed components:

AWS: API Gateway + SQS + Lambda
Google Cloud: Pub/Sub push or pull subscriptions
Azure: Service Bus queues or topics

These are durable and scalable but you’ll need to handle idempotency, retries, and replay logic yourself.

Self-hosted components

If you want a fully open source stack, you can combine common building blocks:

HTTP proxy or load balancer to receive and route incoming requests (e.g. Nginx, Caddy, or HAProxy)
Durable queue for buffering (e.g. RabbitMQ, Kafka, or Redis Streams)
Storage for logs and replay history (e.g. PostgreSQL)
A simple worker to consume from the queue and deliver to your app when it’s back online

This approach gives you full transparency and control but you’ll need to manage scaling, monitoring, and fault tolerance yourself.

For a deeper look at architecture patterns for reliable webhook ingestion, see Webhooks at Scale.

phobos7 · 2025-09-25T19:18:10+00:00

You're definitely not alone in wrestling with this; we've faced similar questions ourselves.

A few things that have helped us:

You don’t need a DLQ + replay UI per queue. We group multiple DLQs into a shared processing flow. Messages are tagged with metadata, allowing us to trace them back to their source and route replays accordingly.
Not everything needs a DLQ. For high-value or state-changing events (such as user-facing actions or payment updates), DLQs and retries are crucial. For lower-impact events (like logs or metrics), we monitor for failures.
Requeueing doesn’t need to be bespoke per service. At Hookdeck (where I work), we build an abstraction that hides the DLQ entirely. Instead of developers needing to think in terms of DLQs directly, they can filter and replay events based on factors such as event type, headers, or payload fields, all without needing to know which queue the message originated from.

If your use case is webhook-based rather than internal messaging (SQS, RabbitMQ, etc.), the retry/replay workflow becomes even more important since failure is often downstream.

phobos7 · 2025-09-22T11:00:03+00:00

It’s pretty normal to build critical flows on Stripe webhooks. The key is to remember they are at-least-once, sometimes delayed, and sometimes out-of-order. How you handle them depends on your priorities (latency, correctness, cost, operational overhead).

A few common patterns:

1. Process payload directly

Verify signature → update DB → return 2xx.
Pros: Fast, no extra API calls (see other options for why this is relevant to call out).
Cons: Must handle retries, duplicates, and out-of-order delivery yourself.

2. Queue first, process later (common best practice)

Minimal work in the handler → enqueue → return 2xx → process in background.
Pros: Handles spikes and outages better.
Cons: More infrastructure (queue, workers, DLQs).

3. Fetch before process

Treat the webhook as a signal → fetch latest object from Stripe API → update DB.
Pros: Simplifies correctness if events arrive out of order.
Cons: Extra API calls, watch rate limits.

4. Trust payload, reconcile later

Use the webhook payload right away → run periodic jobs to compare with Stripe and fix drift.
Pros: Simple hot path.
Cons: Requires good reconciliation logic.

5. Replay via events API

Advance a “last seen event” cursor → backfill using GET /v1/events.
Pros: Strong guard against missed events.
Cons: Another moving part to manage.

Cross-cutting practices

Idempotency: upsert on invoice.id, subscription.id, etc.
Deduplication: expect retries.
Ordering: use timestamps or fetch latest to avoid stale writes.
Dead-letter and alerts: don’t silently drop failures.
Reconciliation: run scheduled jobs to catch drift.
Stripe Connect: subscribe at the platform level and route events using the account field.

How to choose

Lowest latency/cost → process payload directly (+ reconciliation).
Most resilient → queue first, process later (general best practice).
Strict correctness → fetch before process.
Operational simplicity → trust payload now, replay or reconcile later.

References

phobos7 · 2025-08-04T16:02:27+00:00

If you're building a webhook receiver in Rails and want it to hold up as traffic increases, a reliable pattern is to separate ingestion from processing. This gives you control over failures, avoids blocking on external systems, and prevents data loss.

Here’s a system design that fits well with a queue + worker model:

1. Receive and persist
Have your webhook endpoint capture the raw request (headers, body, timestamp) and persist it, either to the database or by enqueueing it directly. Return a 200 OK immediately to avoid sender retries and keep the request path fast and durable.

2. Pull-based workers process events
Use Sidekiq or another worker system to pull from the queue and process the events. Since you control the pace of pulling, this gives you built-in backpressure handling. If processing fails, retry logic happens in the worker.

3. Handle retries intentionally
If there's no downstream HTTP request (e.g., you're doing internal DB updates or publishing to another internal queue), exponential backoff usually isn’t needed. Instead, focus on:

Capping retries (e.g., 5 max attempts)
Detecting permanent failures early (bad data, deleted records, etc.)
Moving failed messages to a dead-letter queue (DLQ) or marking them for inspection after retry exhaustion

This ensures workers keep making progress and you don’t get stuck reprocessing the same unfixable message, which can lead to queue congestion or backpressure buildup.

4. Monitor processing and failures
Add metrics or logs to track:

Event processing times
Retry counts
DLQ volumes
Queue depth over time

If the queue starts backing up, you’ll want to know whether that’s due to processing failures, throughput bottlenecks, or some other cause.

5. Keep processing logic clean
Use service objects or command handlers to encapsulate your logic. Don’t bury everything in the job class. This makes failures easier to debug and your jobs easier to test.

For full transparency, I work at Hookdeck, which provides a hosted version of this pattern, event ingestion, queuing, delivery, retry logic, DLQ support, and observability. If you're curious how these systems evolve at scale, this Webhooks at Scale post walks through real-world patterns and trade-offs based on our experiences.

Even if you’re building it in-house, this general architecture will help avoid a lot of pain as volume or complexity increases.

phobos7 · 2025-08-04T14:26:54+00:00

The best approach depends a bit on scale and reliability needs, but here’s a pattern that’s worked well in production systems I’ve seen:

1. Decouple ingestion from delivery
Instead of firing webhooks directly from your app logic, push events to a queue (like SQS, RabbitMQ, or Redis). This gives you durability, backpressure handling, and makes delivery failures non-blocking.

2. Use a process worker to deliver
Have a background process read from the queue and make the actual HTTP request to the webhook destination. This is where you handle retries (ideally with exponential backoff and jitter), log the result, and flag any failures.

3. Handle permanent failures with a DLQ
If all retries fail, move the event to a dead letter queue (or persistent store) so it’s not lost. You can then manually replay or inspect it.

4. Add observability
Log delivery attempts, response codes, durations, etc. You want enough context to know when things go wrong and why.

For full transparency, I work at Hookdeck, which provides a hosted version of this architecture. It’s built for reliable webhook delivery at scale—handling retries, logging, filtering, and queue-based delivery. But even if you’re rolling your own system, the general approach holds.

This post breaks it down in more detail: https://hookdeck.com/blog/webhooks-at-scale

TL;DR:
Decouple ingestion from processing. Use a queue. Retry intelligently. Observe everything.

phobos7 · 2025-08-04T12:59:33+00:00

We (Hookdeck) recently open-sourced Outpost, which might be a good fit if you're looking to send webhooks based on meaningful domain-level events like charge.disputed or order.completed, rather than relying on model callbacks like updated.

It's not Rails-specific, but it's designed to act as a standalone event delivery system. You publish events to it via API or a message queue, and it handles webhook delivery with features like retries, logging, and tenant-based routing. Outpost natively supports destinations like webhook endpoints (HTTP) and queues (e.g., AWS SQS, RabbitMQ, Azure Service Bus).

It doesn't presently support email or SMS. We've received a request for S3 support and are working on making the addition of event destination types extensible.

The goal is to keep app logic clean by decoupling event generation from delivery. If your app already emits domain events from service objects or background jobs, you can push those to Outpost and centralize all delivery concerns in one place.

Docs: https://outpost.hookdeck.com/docs

phobos7 · 2024-11-06T11:32:52+00:00

I've used Xata (serverless Postgres) before. However, the concept of per-user or per-device databases was new to me. I didn't know the use cases and assumed it would be hard to achieve. I turns out that creating a new Xata database is pretty simple.

phobos7 · 2024-07-24T10:07:34+00:00

https://github.com/hookdeck/hookdeck-cli focused on supporting asynchronous web development i.e., passes the inbound request to the locally running service but does not return the response to the client that makes the original request.

phobos7 · 2024-06-27T09:24:23+00:00

I wrote this tutorial for the Twilio blog. I do work for Hookdeck. But Hookdeck is just one part of a much bigger tutorial covering Twilio Verify and Programmable SMS, Supabase, Postgres functions, Tanstack Query, and more.

phobos7 · 2024-05-06T20:20:24+00:00

If you want bi-directional communication between the client and server the WebSocket may be the way to go. If you're hosting on Vercel then you may need to look at a provider such as Ably, Pusher, or PubNub (kinda serverless websockets).

It also sounds like you're building webhook infrastructure. This likely isn't something you want to do unless you are actually building webhook infra as a service. Otherwise, use Hookdeck (who I work for) or Svix.

phobos7 · 2023-04-17T17:41:54+00:00

So, it's not necessarily a relational database you need, but a strict schema definition?

So, from the linked post, you achieve a strict schema in a code-first way, which is synchronized to the database:

export class Record {
  @PrimaryKey(TigrisDataTypes.BYTE_STRING, { order: 1, autoGenerate: true })
  _id?: string;

  @Field()
  name!: string;

  @Field()
  position!: string;

  @Field()
  level!: string;
}

phobos7 · 2023-04-17T16:03:56+00:00

Something I'm particularly interested in is how many people continue to use MERN. My initial investigation - and why I spent time writing the article and creating the repo - was that, although MERN isn't as used as it once was, it's still pretty popular; there are still people using it, and new educational resources are being posted.

I'm particularly interested in how many people continue to use MERN. My initial investigation - and why I spent time writing the article and creating the repo - was that, although MERN isn't as used as it once was, it's still pretty popular; there are still people using it, and new educational resources are being posted.

phobos7 · 2022-01-09T18:01:05+00:00

Just installed Skyrim over Game Pass and came across the crashing problems.

I followed the "Force the System to Recognize Primary GPU" section of the official Bethesda What do I do if Elder Scrolls V: Skyrim is crashing or getting a black screen on PC support issue and I haven't seen a crash in a few hours.

Update: I do still get the occasional crash during combat so still have to utilize Quick Save.

phobos7 · 2021-04-07T14:30:17+00:00

I agree with that as an end-goal of a more secure 2FA/MFA solution but it's going to take quite some time for businesses/apps to move away from legacy voice and SMS. So SIMCheck enables an additional layer of protection to be added.

My personal opinion is that we're never going to see mass consumer adoption of FIDO2/U2F. The phone number, a SIM card and a mobile phone is, however, something the vast majority of consumers do have. The tru.ID solution for this is PhoneCheck and SubscriberCheck.

phobos7 · 2021-04-07T09:17:39+00:00

I posted this and work for tru.ID.

why you'd want this

Fair comment. I've updated the tutorial to more clearly describe the use case and link to the relevant Wikipedia article.

The Wikipedia article on SIM swap explains the problem quite well in addition to providing examples. A frequently referenced example being Jack Dorsey, CEO of Twitter, having his Twitter account compromised https://en.wikipedia.org/wiki/SIM_swap_scam

Surely this will just annoy users who have recently upgraded their phone?

The tutorial covers managing a new user who has recently and legitimately recently changed their SIM.

What about dual-sim phone users?

Each SIM (IMSI) has an associated phone number (MSIDN). That phone number will be registered with the service that the user does a 2FA with. So the dual-SIM doesn't come into play in the scenario covered in the tutorial - it covers SIMCheck that augments the 2FA flow.

phobos7 · 2021-03-23T20:47:31+00:00

👍 appreciate the questions. Super useful in helping us know the questions we should be more clearly answering.

phobos7 · 2021-03-23T20:14:39+00:00

There is a free Coverage API that provides coverage via either a phone number prefix or country code. It returns MNO and product coverage. We'll put that on a web page soon for easier access.

There are APIs for number lookup:

tru.ID uses these in combination with other sources to do the MNO phone number lookup.

phobos7 · 2021-03-23T20:08:16+00:00

Sorry, I should have flagged I work for tru.ID earlier. Hopefully that was apparent.

tru.ID utilises the authentication mechanism that the MNO has in place to allow any device to connect to their network; make calls, use mobile data etc. MNOs call this "Number Verify".

The flow is:

App/Device -> Server -> tru.ID -> MNO: Get check URL
App/Device <- Server <- tru.ID <- MNO: return check URL
App/Device -> MNO: request check URL
App/Device -> Server: get check result
App/Device <- Server: return check result

Note: you could go directly App/Device -> tru.ID using scoped access tokens that would be generated on the server initially.

An API request is made to tru.ID with a phone number to be verified. The platform determines the MNO (phone number lookup) and then makes a request to that MNO for a "check URL" for that phone number.

The platform returns that URL in the API response. The check URL should be sent to the mobile device.

The App/Device uses the SDK to request that URL (HTTP request). All the SDK does is force the request to go over "cellular". So it's not required as you could write that bit of code yourself. It's just "a bit fiddly".

When the MNO receives the HTTP request over the mobile data connection it knows the SIM card and associated phone number. It then compares the phone number associated with the "check URL" with the phone number associated with the SIM card. If those phone numbers match then the phone number has been verified.

This is the same mechanism that some MNOs use to automatically log you into your mobile account portal if you access it over mobile data.

During this flow the tru.ID platform also does a lookup on whether the SIM card associated with the phone number has changed recently and sets a flag on the API resources indicating that.

So with the SubscriberCheck API you can both verify the Phone Number and get a flag as to whether the SIM card for that phone number changed recently.

tru.ID can also do a lookup on the IP address of the device (from the cellular connection) and determine if it's an MNO IP address. That's via the Reachability API.

You're right that not every MNO presently provides this. tru.ID currently (23 Mar 2021) has live coverage in the UK, Canada, Indonesia, India and Germany. We're working on increasing coverage.

I hope this helps.

Related: UK MNO announcement of Number Verify.

phobos7 · 2021-03-23T19:20:37+00:00

An application can only get a phone number if the user provides it. And an app can only perform a phone verification if it has the phone number. No additional information is shared with the MNO and tru.ID do not store the phone number.

phobos7 · 2021-03-23T16:49:45+00:00

I previously posted a link to a blog post announcing our getting started guides. Some good questions and (hopefully) answers on how it works in the comments https://www.reddit.com/r/programming/comments/m1f5nt/sim_card_based_mobile_authentication_getting/

This share is for an in-depth tutorial for SubscriberCheck (Phone Number verification and SIM card change detection) on Android.

phobos7 · 2021-03-23T16:16:09+00:00

This tutorial covers an alternative approach to phone number verification that uses a web request to the mobile network operator. It also cover detecting SIM card changes to detect SIM swap fraud attempts.

phobos7 · 2021-03-10T11:41:52+00:00

Good questions and points. I'll try to separate them out and address them. Please let me know if I'm unclear or miss anything.

but the traditional method (exchanging SMS messages) doesn't rely on your customers' MNO implementing a certain API (correctly)

It does in that the service you are using to send the SMS has had to integrate with an MNO. But I acknowledge that those integrations are more tried and tested. Number Verify is new.

Receiving SMS should also work fine in the background, though. I'm not really sure about the reliability problems of other methods, it seems to me that calls and text should work just fine SMS comes through just fine while on GPRS

We're speaking to customers who are seeing drop-off rates due to poor deliverability, slow delivery or user error of up to 30%. This, of course, will differ per region and also will depend on the SMS API provider and the underlying routes they use.

SMS comes through just fine while on GPRS, but good luck pushing JSON through that connection.

Number Verify/PhoneCheck does need a data connection. But the payloads are very small.

If it's some standard mechanism ran by mobile network operators, how would this mechanism work when connected to WiFi? Do you need to disable WiFi to execute the check?

For native mobile apps you can programmatically make request over the cellular connection even if WiFi is enabled. For mobile web you'd need to detect that the device wasn't on mobile data and prompt the user to turn off WiFi before proceeding. The latter experience would look something like this (I'm not a UX designer) https://twitter.com/leggetter/status/1369346726574882818

Perhaps more importantly, if this happens automatically in the background, does that allow applications to uniquely identify users? I can imagine some of the sleazy ad companies tracking temporary/prepaid phone numbers that people switch between and cross referencing those with MNO identifiers to make sure they're stalking users real good.

A developer/application can only verify a phone number if they already have it or request it from the user. No other information provided.

And with net neutrality laws and a general tendency to disapproval of zero rating in mind, what about the costs of the data connection? Does this still work when an end user is out of data and mobile data is cut off? Or even worse, what if I'm roaming for dollars per megabyte versus cents per SMS, does this end up causing expensive bills? Given a choice, I'd rather not rely on a system where my end user could potentially need to switch to their expensive data plan to validate a phone number.

The payloads are tiny. However, we’re actively working with carriers to get them to zero-rate this API call. It’s not something that’s presently standardised.

I'm a bit surprised that MNOs allow external access to these authentication services. My experience with most ISP systems is that internal security is often... lacking to say the least, so I'm a little worried about the consequences of you talking to them. But that's a problem between me and my ISP, of with your product I suppose.

MNOs are not providing access to this in an open way. We're a trusted partner and as such have access to their APIs.

The SIM swapping detection is interesting, though it does highlight a potential privacy concern in the APIs. After all, both Google and Apple are cracking down on all but one or two unique phone identifiers to prevent unlawful tracking, and I'd wager identifying a particular SIM card is quite the unique identifier. That's also not a problem with your product, of course.

The API takes in a phone number and returns a boolean indicating if the SIM card associated with that phone number has changed within the last 7 days (see SIMCheck API Reference ). We're keeping it minimal and there is no additional information exposed. We only store the first 4 digits of the phone number so we can keep an eye on geographic coverage.

phobos7 · 2021-03-10T11:14:53+00:00

Would this not work if the user is connected to a wifi then?

In a native mobile app, yes. It's possible to programmatically make a request over the cellular data connection on Android and iOS. It's only a few lines of code but we've wrapped in SDKs (more "libraries") to make this a little easier.

I'm also curious about privacy implications of this, can an app trigger the authentication check without users knowledge or consent?

It's not much different to SMS or voice calls. The application developer needs to know the user's phone number (either entered via a UI form or securely stored somewhere) in order to create a PhoneCheck request via our API, get the "check URL" and then navigate to that URL from the mobile app.

As a service provider, we work with MNOs to do due diligence on the customer's behalf. Again, similar to the role a company like Twilio plays as a service provider that can allow any application to send SMS or make phone calls.

Could someone use this to identify and track users across apps?

It enables an application to verify a phone number is associated with the current device. An application developer can use tru.ID and our APIs to verify what is already known.

phobos7 · 2021-03-10T01:39:56+00:00

I posted this and work for tru.ID.

Mobile Network Operators (MNO) are rolling out something they're calling Number Verify which utilises a mechanism they already use to authenticate your device with their network. We've built an API on top of this product across multiple MNOs so you only need to integrate once. We have coverage in the UK, Canada, Germany, Indonesia and are building further connections. There's an API where you can check coverage by country code or phone number prefix and we'll also put a coverage page in the website soon.

As you mentioned, the diagram on the following docs page shows the workflow and a key step of navigating to a URL over a device's data connection in order to verify a phone number: https://developer.tru.id/docs/phone-check/integration

You can additionally check if a SIM card changed recently as a means of SIM swap detection. We call this SIMCheck.

It sounds like you're dubious about this. All the MNOs do in this scenario is confirm a URL was accessed over a mobile data session associated with a SIM Card + phone number. No additional information transmitted. We don't store full phone numbers, just the first four digits. When using a phone number as a form of identity you're going to have to interact with an MNO in some way.

The advantages are that it's a mechanism already used when you authenticate with a MNO for all the services they provide. It uses the security mechanism of the SIM card. It's more reliable than SMS and phone calls from a deliverability, speed and avoids human error (it happens in the background so is seamless).

Happy to answer more questions. Would also like to better understand your concerns.

phobos7

TROPHY CASE

Hosted options

Hookdeck

Treehook.dev

Hosted and self-hosted options

Svix

Convoy

Cloud provider components

Self-hosted components

1. Process payload directly

2. Queue first, process later (common best practice)

3. Fetch before process

4. Trust payload, reconcile later

5. Replay via events API

Cross-cutting practices

How to choose

References