---
title: Bimka Space
description: QStash is a fully managed serverless queue and messaging service designed for the serverless era.
date: "2022-07-18"
url: https://upstash.com/qstash
published: true

---

QStash is an HTTP based messaging and scheduling solution for the serverless and edge runtimes.

- 100% serverless, no stateful connections required. Messages are pushed to your API.
- At-least-once delivery guaranteed to any public API
- Pubsub via topics
- Delay message delivery
- Message deduplication
- Scheduling via CRON


Formally, QStash is a message queue and task scheduler designed for serverless runtimes. Informally, QStash is a glue for your serverless functions.

There was a perception serverless was only good for simple tasks. Not anymore. People build powerful systems with serverless stack. Powerful systems are composed of multiple components. Communication among those components is a big engineering problem. There are already great solutions for this problem. But we think existing solutions do not fit in serverless space. Either they are too complex or not designed to work with stateless runtimes. So we want a solution which (is):

- Works anywhere including serverless and edge.
- Messaging as a service with no backend for users to run.
- Lightweight, easy to understand, requires nothing to learn.
- Price scales to zero.

Let's talk about a real world example. We have an e-commerce app and we want to send an informational email after each purchase. We have a service (an API route) for new purchases (newPurchase) and a second service for sending emails and notifications (sendEmail). We can call the sendEmail service from the newPurchase service. But what if the call fails? Should we wait for the response and retry? What if too many calls congest the sendEmail service and the service does not respond on time? You need to handle all these cases in your newPurchase service. Moreover, when you change the contract of sendEmail service; you have to update your newPurchase service too.

If you use QStash in the above example, you simply send a request to QStash from the newPurchase service. QStash will queue the request and call the sendEmail service. If the service does not respond, QStash will retry with a backoff strategy. The latency of sendEmail service will not affect the newPurchase service, because it will not wait for a response from the sendEmail service. QStash decouples the newPurchase and sendEmail services. You can update both services independently as long as you keep the message format compatible.

With QStash, you can add delays to the requests. Send an email 3 days after the shipment to remind the customer to add a review. You can also schedule tasks. You can send the requests with a CRON expression, so it will be run repetitively.


To learn more about QStash, visit [upstash.com/qstash](upstash.com/qstash).
