> For the complete documentation index, see [llms.txt](https://docs.joobq.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.joobq.io/quick-start.md).

# Quick Start

Run a typed order-processing job with Crystal and Redis.

You will enqueue order `42`, see a worker process it, and stop the worker cleanly. Have Crystal **1.22.1**, Shards, and a local Redis instance ready. The short path targets about three minutes with prerequisites installed; dependency downloads and cold compilation vary by machine.

## 1. Create the project

```sh
mkdir order_worker
cd order_worker
mkdir src
```

{% code title="shard.yml" %}

```yaml
name: order_worker
version: 0.1.0

dependencies:
  joobq:
    github: azutoolkit/joobq
    version: "= 0.5.1"
```

{% endcode %}

```sh
shards install
redis-cli ping
```

Expect `PONG`. This walkthrough uses the default local Redis connection. Use a dedicated development instance; see [Redis configuration](/configuration/redis.md) for other endpoints. Commit `shard.lock` with your application.

## 2. Write the job and register its queue

{% code title="src/worker.cr" %}

```crystal
require "joobq"

struct ProcessOrderJob
  include JoobQ::Job

  @queue = "orders"
  getter order_id : Int64

  def initialize(@order_id : Int64)
  end

  def perform
    puts "Processed order #{order_id}"
  end
end

JoobQ.configure do |config|
  config.rest_api_enabled = false
  queue "orders", 2, ProcessOrderJob
end

ProcessOrderJob.enqueue(order_id: 42_i64)
JoobQ.forge
```

{% endcode %}

The queue name on the job matches the registered queue. `enqueue` stores work; `forge` starts workers and waits. The handler prints a message instead of calling a real payment or mail service.

## 3. Run it

```sh
crystal run src/worker.cr
```

Among the startup logs, expect:

```
Processed order 42
```

Press **Ctrl-C** after completion. JoobQ stops accepting work and drains its workers. Each launch of this demonstration enqueues a new job; a real producer normally lives separately from worker startup.

\[Screenshot: A terminal showing the Quick Start worker starting the orders queue, printing Processed order 42, and exiting after Ctrl-C without exposing connection credentials.]

{% hint style="info" %}
The management API is deliberately off. No management token is needed for this example. A job that performs an external effect still needs [idempotency](/best-practices/idempotency.md).
{% endhint %}

**Next:** [Queues and workers](/core/queues-workers.md), or [integrate an Azu app](/quick-start/azu-application.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.joobq.io/quick-start.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.