course-definition.yml

slug: "redis"
name: "Build your own Redis"
short_name: "Redis"
release_status: "live"

description_md: |-
  Redis is an in-memory data structure store often used as a database, cache, message broker and streaming engine. In this challenge
  you'll build your own Redis server that is capable of serving basic commands, reading RDB files and more.

  Along the way, you'll learn about TCP servers, the Redis Protocol and more.

short_description_md: |-
  Learn about TCP servers, the Redis protocol and more

completion_percentage: 30
concept_slugs: ["network-protocols", "tcp-overview"]

languages:
  - slug: "c"
  - slug: "clojure"
  - slug: "cpp"
  - slug: "crystal"
  - slug: "csharp"
  - slug: "elixir"
  - slug: "gleam"
  - slug: "go"
  - slug: "haskell"
  - slug: "java"
  - slug: "javascript"
  - slug: "php"
  - slug: "python"
  - slug: "ruby"
  - slug: "rust"
  - slug: "typescript"
  - slug: "scala"
    release_status: "beta"

marketing:
  difficulty: medium
  sample_extension_idea_title: "Persistence"
  sample_extension_idea_description: "A Redis server that can read and write .rdb files"
  testimonials:
    - author_name: "Charles Guo"
      author_description: "Software Engineer, Stripe"
      author_avatar: "https://codecrafters.io/images/external/testimonials/charles-guo.png"
      link: "https://github.com/shaldengeki"
      text: |-
        The Redis challenge was extremely fun. I ended up having to read the
        Redis Protocol specification doc pretty carefully in its entirety! The result
        felt like lightly-guided independent study, if that makes sense. (Which, again, was lots of fun)
    - author_name: "Patrick Burris"
      author_description: "Senior Software Developer, CenturyLink"
      author_avatar: "https://codecrafters.io/images/external/testimonials/patrick-burris.jpeg"
      link: "https://github.com/Jumballaya"
      text: |-
        I think the instant feedback right there in the git push is really cool.
        Didn't even know that was possible!

extensions:
  - slug: "persistence-rdb"
    name: "RDB Persistence"
    description_markdown: |
      In this challenge extension you'll add [persistence][redis-persistence] support to your Redis implementation.

      Along the way you'll learn about Redis's [RDB file format][rdb-file-format] and more.

      [redis-persistence]: https://redis.io/docs/manual/persistence/
      [rdb-file-format]: https://github.com/sripathikrishnan/redis-rdb-tools/blob/548b11ec3c81a603f5b321228d07a61a0b940159/docs/RDB_File_Format.textile

  - slug: "replication"
    name: "Replication"
    description_markdown: |
      In this challenge extension you'll add support for [Replication][redis-replication] to your Redis implementation.

      Along the way you'll learn about how Redis's leader-follower replication works, the [PSYNC][redis-psync-command] command and more.

      [redis-replication]: https://redis.io/docs/management/replication/
      [redis-psync-command]: https://redis.io/commands/psync/

  - slug: "streams"
    name: "Streams"
    description_markdown: |-
      In this challenge extension you'll add support for the [Stream][redis-streams-data-type] data type to your Redis implementation.

      Along the way you'll learn about commands like [XADD][xadd-command], [XRANGE][xrange-command] and more.

      [redis-streams-data-type]: https://redis.io/docs/data-types/streams/
      [xadd-command]: https://redis.io/commands/xadd/
      [xrange-command]: https://redis.io/commands/xrange/

stages:
  - slug: "init"
    concept_slugs:
      ["network-protocols", "tcp-overview", "go-tcp-server", "rust-tcp-server"]
    name: "Bind to a port"
    description_md: |-
      In this stage, you'll implement a TCP server that listens on port 6379.

      [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) is the underlying protocol used by protocols like HTTP, SSH and others
      you're probably familiar with. Redis clients & servers use TCP to communicate with each other.

      Don't worry if you're unfamiliar with the TCP protocol, or what Redis clients & servers are. You'll learn more about this in the
      next stages.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then try to connect to your TCP server on port 6379. If the connection succeeds, you'll pass this stage.

      ### Notes

      - 6379 is the default port that Redis uses.
      - If you already have a Redis server running on your machine and listening on port 6379, you'll see a "port already in use" error when running your code. Try stopping the existing Redis server and running your code again.
    difficulty: very_easy
    marketing_md: |-
      In this stage, you'll start a TCP server on port 6379, which is the
      default port that Redis uses.
    tester_source_code_url: "https://github.com/codecrafters-io/redis-tester/blob/a58b9d58b33870fe26a164c0e323f809275a7250/internal/test_bind.go#L11"

  - slug: "ping-pong"
    concept_slugs:
      ["network-protocols", "tcp-overview", "go-tcp-server", "rust-tcp-server"]
    name: "Respond to PING"
    difficulty: easy
    description_md: |-
      In this stage, you'll implement support for the [PING](https://redis.io/commands/ping) command.

      Redis clients communicate with Redis servers by sending "[commands](https://redis.io/commands/)". For each command, a Redis server sends a response back to the client.
      Commands and responses are both encoded using the [Redis protocol](https://redis.io/topics/protocol) (we'll learn more about this in later stages).

      [PING](https://redis.io/commands/ping/) is one of the simplest Redis commands. It's used to check whether a Redis server is healthy.

      The response for the `PING` command is `+PONG\r\n`. This is the string "PONG" encoded using the [Redis protocol](https://redis.io/docs/reference/protocol-spec/).

      In this stage, we'll cut corners by ignoring client input and hardcoding `+PONG\r\n` as a response. We'll learn to parse client input in later stages.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then send a `PING` command to your server and expect a `+PONG\r\n` response.

      ```bash
      $ redis-cli PING
      ```

      Your server should respond with `+PONG\r\n`, which is "PONG" encoded as a [RESP simple string](https://redis.io/docs/reference/protocol-spec/#resp-simple-strings).

      ### Notes

      - You can ignore the data that the tester sends you for this stage. We'll get to parsing
      client input in later stages. For now, you can just hardcode `+PONG\r\n` as the response.
      - You can also ignore handling multiple clients and handling multiple PING commands in the stage, we'll get to that in later stages.
      - The exact bytes your program will receive won't be just `PING`, you'll receive something like this: `*1\r\n$4\r\nPING\r\n`,
      which is the Redis protocol encoding of the `PING` command. We'll learn more about this in later stages.
    marketing_md: |
      In this stage, you'll respond to the
      [PING](https://redis.io/commands/ping) command. You'll use [the Redis
      protocol](https://redis.io/topics/protocol) to encode the reply.
    tester_source_code_url: "https://github.com/codecrafters-io/redis-tester/blob/a58b9d58b33870fe26a164c0e323f809275a7250/internal/test_ping_pong.go#L9"

  - slug: "ping-pong-multiple"
    concept_slugs:
      ["network-protocols", "tcp-overview", "go-tcp-server", "rust-tcp-server"]
    name: "Respond to multiple PINGs"
    difficulty: easy
    description_md: |-
      In this stage, you'll respond to multiple
      [PING](https://redis.io/commands/ping) commands sent by the same connection.

      A Redis server starts to listen for the next command as soon as it's done responding to the previous one. This allows
      Redis clients to send multiple commands using the same connection.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then send two PING commands using the same connection:

      ```bash
      $ echo -e "PING\nPING" | redis-cli
      ```

      The tester will expect to receive two `+PONG\r\n` responses.

      {{#lang_is_javascript}}
      In most languages, you'd need to run a loop that reads input from a connection and sends a
      response back. In JavaScript however, if you're listening to the
      [`data`](https://nodejs.org/api/net.html#net_event_data) event, this should be automatically handled for you. **It
      is very likely that the code you had for the previous stage will pass this stage without any changes!**
      {{/lang_is_javascript}}

      {{^lang_is_javascript}}
      You'll need to run a loop that reads input from a connection and sends a
      response back.
      {{/lang_is_javascript}}

      ### Notes

      - Just like the previous stage, you can hardcode `+PONG\r\n` as the response for this stage. We'll get to parsing
       client input in later stages.
      - The two PING commands will be sent using the same connection. We'll get to handling multiple connections in later stages.
    marketing_md: |-
      In this stage, you'll respond to multiple
      [PING](https://redis.io/commands/ping) commands sent by the same client.
    tester_source_code_url: "https://github.com/codecrafters-io/redis-tester/blob/a58b9d58b33870fe26a164c0e323f809275a7250/internal/test_ping_pong.go#L35"

  - slug: "concurrent-clients"
    concept_slugs:
      ["network-protocols", "tcp-overview", "go-tcp-server", "rust-tcp-server"]
    name: "Handle concurrent clients"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for multiple concurrent clients.

      In addition to handling multiple commands from the same client, Redis servers are also designed to handle multiple clients at once.

      {{#lang_is_javascript}}
      In most languages, you'd need to either use threads or implement an
      [Event Loop](https://en.wikipedia.org/wiki/Event_loop) to do this. In JavaScript however, since [the concurrency
      model itself is based on an event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop), most
      standard library functions are designed to support this kind of concurrent behaviour out of the box. **It is very
      likely that the code you had for the previous stage will pass this stage without any changes!**
      {{/lang_is_javascript}}

      {{^lang_is_javascript}}
      To implement this, you'll need to either use threads, or, if you're feeling
      adventurous, an [Event Loop](https://en.wikipedia.org/wiki/Event_loop) (like
      the official Redis implementation does).
      {{/lang_is_javascript}}

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then send two PING commands concurrently using two different connections:

      ```bash
      # These two will be sent concurrently so that we test your server's ability to handle concurrent clients.
      $ redis-cli PING
      $ redis-cli PING
      ```

      The tester will expect to receive two `+PONG\r\n` responses.

      ### Notes

      - Since the tester client _only_ sends the PING command at the moment, it's okay to
        ignore what the client sends and hardcode a response. We'll get to parsing
        client input in later stages.
    marketing_md: |-
      In this stage, you'll add support for multiple concurrent clients to your
      Redis server. To achieve this you'll use an [Event
      Loop](https://en.wikipedia.org/wiki/Event_loop),
      like the official Redis implementation does.
    tester_source_code_url: "https://github.com/codecrafters-io/redis-tester/blob/a58b9d58b33870fe26a164c0e323f809275a7250/internal/test_ping_pong.go#L56"

  - slug: "echo"
    name: "Implement the ECHO command"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the [ECHO](https://redis.io/commands/echo) command.

      `ECHO` is a command like `PING` that's used for testing and debugging. It accepts a single argument and returns it back as a
      RESP bulk string.

      ```bash
      $ redis-cli PING # The command you implemented in previous stages
      PONG
      $ redis-cli ECHO hey # The command you'll implement in this stage
      hey
      ```

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then send an `ECHO` command with an argument to your server:

      ```bash
      $ redis-cli ECHO hey
      ```

      The tester will expect to receive `$3\r\nhey\r\n` as a response (that's the string `hey` encoded as a [RESP bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings).

      ### Notes

      - We suggest that you implement a proper Redis protocol parser in this stage. It'll come in handy in later stages.
      - Redis command names are case-insensitive, so `ECHO`, `echo` and `EcHo` are all valid commands.
      - The tester will send a random string as an argument to the `ECHO` command, so you won't be able to hardcode the response to pass this stage.
      - The exact bytes your program will receive won't be just `ECHO hey`, you'll receive something like this: `*2\r\n$4\r\nECHO\r\n$3\r\nhey\r\n`. That's
        `["ECHO", "hey"]` encoded using the [Redis protocol](https://redis.io/docs/reference/protocol-spec/).
      - You can read more about how "commands" are handled in the Redis protocol [here](https://redis.io/docs/reference/protocol-spec/#sending-commands-to-a-redis-server).
    marketing_md: |-
      In this stage, you'll respond to the
      [ECHO](https://redis.io/commands/echo) command. You'll parse user input
      according to the [the Redis protocol
      specification](https://redis.io/topics/protocol).
    tester_source_code_url: "https://github.com/codecrafters-io/redis-tester/blob/a58b9d58b33870fe26a164c0e323f809275a7250/internal/test_echo.go#L11"

  # TODO: Change this to use hyphens
  - slug: "set_get"
    name: "Implement the SET & GET commands"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the [SET](https://redis.io/commands/set) &
      [GET](https://redis.io/commands/get) commands.

      The `SET` command is used to set a key to a value. The `GET` command is used to retrieve the value of a key.

      ```bash
      $ redis-cli SET foo bar
      OK
      $ redis-cli GET foo
      bar
      ```

      The `SET` command supports a number of extra options like `EX` (expiry time in seconds), `PX` (expiry time in milliseconds) and more. We
      won't cover these extra options in this stage. We'll get to them in later stages.

      ### Tests

      The tester will execute your program like this:

      ```bash
      ./spawn_redis_server.sh
      ```

      It'll then send a `SET` command to your server:

      ```bash
      $ redis-cli SET foo bar
      ```

      The tester will expect to receive `+OK\r\n` as a response (that's the string `OK` encoded as a [RESP simple string](https://redis.io/docs/reference/protocol-spec/#resp-simple-strings)).

      This command will be followed by a `GET` command:

      ```bash
      $ redis-cli GET foo
      ```

      The tester will expect to receive `$3\r\nbar\r\n` as a response (that's the string `bar` encoded as a [RESP bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings).

      ### Notes

      - If you implemented a proper Redis protocol parser in the previous stage, you should be able to reuse it in this stage.
      - Just like the previous stage, the values used for keys and values will be random, so you won't be able to hardcode the response to pass this stage.
      - If a key doesn't exist, the `GET` command should return a "null bulk string" (`$-1\r\n`). We won't explicitly test this in this stage, but you'll need it for the next stage (expiry).
    marketing_md: |-
      In this stage, you'll need to implement the
      [SET](https://redis.io/commands/set) &
      [GET](https://redis.io/commands/get) commands.
    tester_source_code_url: "https://github.com/codecrafters-io/redis-tester/blob/a58b9d58b33870fe26a164c0e323f809275a7250/internal/test_get_set.go#L11"

  - slug: "expiry"
    name: "Expiry"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for setting a key with an expiry.

      The expiry for a key can be provided using the "PX" argument to the [SET](https://redis.io/commands/set) command. The expiry is provided in milliseconds.

      ```bash
      $ redis-cli SET foo bar px 100 # Sets the key "foo" to "bar" with an expiry of 100 milliseconds
      OK
      ```

      After the key has expired, a `GET` command for that key should return a "null bulk string" (`$-1\r\n`).

      {{#lang_is_haskell}}
      The [time](https://hackage.haskell.org/package/time) package is available
      to use as a dependency.
      {{/lang_is_haskell}}

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then send a `SET` command to your server to set a key with an expiry:

      ```bash
      $ redis-cli SET foo bar px 100
      ```

      It'll then immediately send a `GET` command to retrieve the value:

      ```bash
      $ redis-cli GET foo
      ```

      It'll expect the response to be `bar` (encoded as a RESP bulk string).

      It'll then wait for the key to expire and send another `GET` command:

      ```bash
      $ sleep 0.2 && redis-cli GET foo
      ```

      It'll expect the response to be `$-1\r\n` (a "null bulk string").

      ### Notes

      - Just like command names, command arguments are also case-insensitive. So `PX`, `px` and `pX` are all valid.
      - The keys, values and expiry times used in the tests will be random, so you won't be able to hardcode a response to pass this stage.
    marketing_md: |-
      In this stage, you'll add support for setting a key with an expiry. The
      expiry is provided using the "PX" argument to the
      [SET](https://redis.io/commands/set) command.
    tester_source_code_url: "https://github.com/codecrafters-io/redis-tester/blob/master/internal/test_expiry.go"

  # Persistence

  - slug: "rdb-config"
    primary_extension_slug: "persistence-rdb"
    name: "RDB file config"
    difficulty: easy
    description_md: |
      Welcome to the RDB Persistence Extension! In this extension, you'll add support for reading [RDB files](https://redis.io/docs/management/persistence/) (Redis Database files).

      In this stage, you'll add support for two configuration parameters related to RDB persistence, as well as the [CONFIG GET](https://redis.io/docs/latest/commands/config-get/) command.

      ### RDB files

      An RDB file is a point-in-time snapshot of a Redis dataset. When RDB persistence is enabled, the Redis server syncs its in-memory state with an RDB file, by doing the following:

      1.  On startup, the Redis server loads the data from the RDB file.
      2.  While running, the Redis server periodically takes new snapshots of the dataset, in order to update the RDB file.

      ###  `dir` and `dbfilename`

      The configuration parameters `dir` and `dbfilename` specify where an RDB file is stored:
      -   `dir` - the path to the directory where the RDB file is stored (example: `/tmp/redis-data`)
      -   `dbfilename` - the name of the RDB file (example: `rdbfile`)

      ### The `CONFIG GET` command

      The [`CONFIG GET`](https://redis.io/docs/latest/commands/config-get/) command returns the values of configuration parameters.

      It takes in one or more configuration parameters and returns a [RESP array](https://redis.io/docs/latest/develop/reference/protocol-spec/#arrays) of key-value pairs:

      ```bash
      $ redis-cli CONFIG GET dir
      1) "dir"
      2) "/tmp/redis-data"
      ```

      Although `CONFIG GET` can fetch multiple parameters at a time, the tester will only send `CONFIG GET` commands with one parameter at a time.

      ### Tests

      The tester will execute your program like this:

      ```bash
      ./spawn_redis_server.sh --dir /tmp/redis-files --dbfilename dump.rdb
      ```

      It'll then send the following commands:

      ```bash
      $ redis-cli CONFIG GET dir
      $ redis-cli CONFIG GET dbfilename
      ```

      Your server must respond to each `CONFIG GET` command with a RESP array containing two elements:

      1.  The parameter **name**, encoded as a [RESP Bulk string](https://redis.io/docs/latest/develop/reference/protocol-spec/#bulk-strings)
      2.  The parameter **value**, encoded as a RESP Bulk string

      For example, if the value of `dir` is `/tmp/redis-files`, then the expected response to `CONFIG GET dir` is:

      ```bash
      *2\r\n$3\r\ndir\r\n$16\r\n/tmp/redis-files\r\n
      ```

      ### Notes

      1.  You don't need to read the RDB file in this stage, you only need to store `dir` and `dbfilename`. Reading from the file will be covered in later stages.
      2.  If your repository was created before 5th Oct 2023, it's possible that your `./spawn_redis_server.sh` script is not passing arguments to your program. To fix this, you'll need to edit `./spawn_redis_server.sh`. Check the [update CLI args PR](https://github.com/codecrafters-io/build-your-own-redis/pull/89/files) for details on how to do this.
    marketing_md: |
      In this stage, you'll add support for reading the config values related to where RDB files are stored. You'll implement the `CONFIG GET` command.

  - slug: "rdb-read-key"
    primary_extension_slug: "persistence-rdb"
    name: "Read a key"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for reading a key from an RDB file.

      To keep things simple, we'll start out by supporting RDB files that contain a single key.

      Jan-Erik Rediger (author of [rdb-rs](https://rdb.fnordig.de/)) has a great [write-up](https://rdb.fnordig.de/file_format.html)
      that explains the RDB file format in detail. We recommend using it as a reference when working on this stage.

      The tester will create an RDB file with a single key and execute your program like this:

      ```
      ./spawn_redis_server.sh --dir <dir> --dbfilename <filename>
      ```

      It'll then send a `KEYS *` command to your server.

      ```bash
      $ redis-cli KEYS "*"
      ```

      The response to `KEYS *` should be a RESP array with one element: the key.

      For example, let's say the RDB file contains a key called `foo`. The expected response will be:

      ```
      *1\r\n$3\r\nfoo\r\n
      ```

      - `*1\r\n` indicates that the array has one element
      - `$3\r\nfoo\r\n` indicates that the first element is a bulk string with the value `foo`

      **Note**: Remember, in this stage you only need to support RDB files that contain a single key, and you can ignore the value of the key. We'll
      get to handling multiple keys and reading values in later stages.

      **Note**: The `.rdb` file provided via `--dir`/`--dbfilename` might not exist. If the file doesn't exist, your program must treat it as if the database
      is currently empty.
    marketing_md: |
      In this stage, you'll add support for reading a key from an RDB file that contains a single key-value pair. You'll do this by implementing the `KEYS *` command.

  - slug: "rdb-read-string-value"
    primary_extension_slug: "persistence-rdb"
    name: "Read a string value"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for reading the value corresponding to a key from an RDB file.

      Just like with the previous stage, we'll stick to supporting RDB files that contain a single key for now.

      The tester will create an RDB file with a single key and execute your program like this:

      ```
      ./spawn_redis_server.sh --dir <dir> --dbfilename <filename>
      ```

      It'll then send a `GET <key>` command to your server.

      ```bash
      $ redis-cli GET "foo"
      ```

      The response to `GET <key>` should be a RESP bulk string with the value of the key.

      For example, let's say the RDB file contains a key called `foo` with the value `bar`. The expected response will be `$3\r\nbar\r\n`.

      Strings can be encoded in three different ways in the RDB file format:

      - Length-prefixed strings
      - Integers as strings
      - Compressed strings

      In this stage, you only need to support length-prefixed strings. We won't cover the other two types in this challenge.

      We recommend using [this blog post](https://rdb.fnordig.de/file_format.html) as a reference when working on this stage.
    marketing_md: |
      In this stage, you'll add support for reading the value of a key from an RDB file that contains a single key-value pair.

  - slug: "rdb-read-multiple-keys"
    primary_extension_slug: "persistence-rdb"
    name: "Read multiple keys"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for reading multiple keys from an RDB file.

      The tester will create an RDB file with multiple keys and execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh --dir <dir> --dbfilename <filename>
      ```

      It'll then send a `KEYS *` command to your server.

      ```bash
      $ redis-cli KEYS "*"
      ```

      The response to `KEYS *` should be a RESP array with the keys as elements.

      For example, let's say the RDB file contains two keys: `foo` and `bar`. The expected response will be:

      ```
      *2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n
      ```

      - `*2\r\n` indicates that the array has two elements
      - `$3\r\nfoo\r\n` indicates that the first element is a bulk string with the value `foo`
      - `$3\r\nbar\r\n` indicates that the second element is a bulk string with the value `bar`
    marketing_md: |
      In this stage, you'll add support for reading multiple keys from an RDB file. You'll do this by extending the `KEYS *` command to support multiple keys.

  - slug: "rdb-read-multiple-string-values"
    primary_extension_slug: "persistence-rdb"
    name: "Read multiple string values"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for reading multiple string values from an RDB file.

      The tester will create an RDB file with multiple keys and execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh --dir <dir> --dbfilename <filename>
      ```

      It'll then send multiple `GET <key>` commands to your server.

      ```bash
      $ redis-cli GET "foo"
      $ redis-cli GET "bar"
      ```

      The response to each `GET <key>` command should be a RESP bulk string with the value corresponding to the key.
    marketing_md: |
      In this stage, you'll add support for reading multiple string values from an RDB file.

  - slug: "rdb-read-value-with-expiry"
    primary_extension_slug: "persistence-rdb"
    name: "Read value with expiry"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for reading values that have an expiry set.

      The tester will create an RDB file with multiple keys. Some of these keys will have an expiry set, and some won't. The expiry timestamps
      will also be random, some will be in the past and some will be in the future.

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh --dir <dir> --dbfilename <filename>
      ```

      It'll then send multiple `GET <key>` commands to your server.

      ```bash
      $ redis-cli GET "foo"
      $ redis-cli GET "bar"
      ```

      When a key has expired, the expected response is `$-1\r\n` (a "null bulk string").

      When a key hasn't expired, the expected response is a RESP bulk string with the value corresponding to the key.
    marketing_md: |
      In this stage, you'll add support for reading values that have an expiry set.

  # Replication

  - slug: "repl-custom-port"
    primary_extension_slug: "replication"
    name: "Configure listening port"
    difficulty: easy
    description_md: |
      Welcome to the Replication extension!

      In this extension, you'll extend your Redis server to support [leader-follower replication](https://redis.io/docs/management/replication/). You'll be able to run
      multiple Redis servers with one acting as the "master" and the others as "replicas". Changes made to the master will be automatically replicated to replicas.

      Since we'll need to run multiple instances of your Redis server at once, we can't run all of them on port 6379.

      In this stage, you'll add support for starting the Redis server on a custom port. The port number will be passed to your program via the `--port` flag.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port 6380
      ```

      It'll then try to connect to your TCP server on the specified port number (`6380` in the example above). If the connection succeeds, you'll pass this stage.

      ### Notes

      - Your program still needs to pass the previous stages, so if `--port` isn't specified, you should default to port 6379.
      - The tester will pass a random port number to your program, so you can't hardcode the port number from the example above.
      - If your repository was created before 5th Oct 2023, it's possible that your `./spawn_redis_server.sh` script
      might not be passing arguments on to your program. You'll need to edit `./spawn_redis_server.sh` to fix this, check
      [this PR](https://github.com/codecrafters-io/build-your-own-redis/pull/89/files) for details.
    marketing_md: |
      In this stage, you'll add support for parsing the `--port` flag and starting Redis on a custom port.

  - slug: "repl-info"
    primary_extension_slug: "replication"
    name: "The INFO command"
    difficulty: easy
    description_md: |
      In this stage, you'll add support for the [INFO](https://redis.io/commands/info/) command.

      The `INFO` command returns information and statistics about a Redis server. In this stage, we'll add support for the
      `replication` section of the `INFO` command.

      ### The replication section

      When you run the `INFO` command against a Redis server, you'll see something like this:

      ```
      $ redis-cli INFO replication
      # Replication
      role:master
      connected_slaves:0
      master_replid:8371b4fb1155b71f4a04d3e1bc3e18c4a990aeeb
      master_repl_offset:0
      second_repl_offset:-1
      repl_backlog_active:0
      repl_backlog_size:1048576
      repl_backlog_first_byte_offset:0
      repl_backlog_histlen:
      ```

      The reply to this command is a [Bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings) where each line is a key value pair, separated by ":".

      Here are what some of the important fields mean:

      - `role`: The role of the server (`master` or `slave`)
      - `connected_slaves`: The number of connected replicas
      - `master_replid`: The replication ID of the master (we'll get to this in later stages)
      - `master_repl_offset`: The replication offset of the master (we'll get to this in later stages)

      In this stage, you'll only need to support the `role` key. We'll add support for other keys in later stages.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT>
      ```

      It'll then send the `INFO` command with `replication` as an argument.

      ```bash
      $ redis-cli -p <PORT> info replication
      ```

      Your program should respond with a [Bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings) where each line
      is a key value pair separated by `:`. The tester will only look for the `role` key, and assert that the value is `master`.

      ### Notes

      - In the response for the `INFO` command, you only need to support the `role` key for this stage. We'll add support for the other keys in later stages.
      - The `# Replication` heading in the response is optional, you can ignore it.
      - The response to `INFO` needs to be encoded as a [Bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings).
        - An example valid response would be `$11\r\nrole:master\r\n` (the string `role:master` encoded as a [Bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings))
      - The `INFO` command can be used without any arguments, in which case it returns all sections available. In this stage, we'll
        always send `replication` as an argument to the `INFO` command, so you only need to support the `replication` section.
    marketing_md: |
      In this stage, you'll add support for the INFO command on the master.

  - slug: "repl-info-replica"
    primary_extension_slug: "replication"
    name: "The INFO command on a replica"
    difficulty: medium
    description_md: |
      In this stage, you'll extend your [INFO](https://redis.io/commands/info/) command to run on a replica.

      ### The `--replicaof` flag

      By default, a Redis server assumes the "master" role. When the `--replicaof` flag is passed, the server assumes the "slave" role instead.

      Here's an example usage of the `--replicaof` flag:

      ```
      ./spawn_redis_server.sh --port 6380 --replicaof localhost 6379
      ```

      In this example, we're starting a Redis server in replica mode. The server itself will listen for connections on port 6380, but it'll
      also connect to a master (another Redis server) running on localhost port 6379 and replicate all changes from the master.

      We'll learn more about how this replication works in later stages. For now, we'll focus on adding support for the `--replicaof` flag, and
      extending the `INFO` command to support returning `role: slave` when the server is a replica.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT> --replicaof <MASTER_HOST> <MASTER_PORT>
      ```

      It'll then send the `INFO` command with `replication` as an argument to your server.

      ```bash
      $ redis-cli -p <PORT> info replication
      ```

      Your program should respond with a [Bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings) where each line
      is a key value pair separated by `:`. The tester will only look for the `role` key, and assert that the value is `slave`.

      ### Notes

      - Your program still needs to pass the previous stage tests, so if `--replicaof` isn't specified, you should default to the `master` role.
      - Just like the last stage, you only need to support the `role` key in the response for this stage. We'll add support for the other keys in later stages.
      - You don't need to actually connect to the master server specified via `--replicaof` in this stage. We'll get to that in later stages.
    marketing_md: |
      In this stage, you'll add support for the --replicaof arg and INFO command on the replica.

  - slug: "repl-id"
    primary_extension_slug: "replication"
    name: "Initial Replication ID and Offset"
    difficulty: easy
    description_md: |
      In this stage, you'll extend your `INFO` command to return two additional values: `master_replid` and `master_repl_offset`.

      ### The replication ID and offset

      Every Redis master has a replication ID: it is a large pseudo random string. This is set when the master is booted. Every time
      a master instance restarts from scratch, its replication ID is reset.

      Each master also maintains a "replication offset" corresponding to how many bytes of commands have been added to the replication
      stream. We'll learn more about this offset in later stages. For now, just know that the value starts from `0` when a master is
      booted and no replicas have connected yet.

      In this stage, you'll initialize a replication ID and offset for your master:

      - The ID can be any pseudo random alphanumeric string of 40 characters.
        - For the purposes of this challenge, you don't need to actually generate a random string, you can hardcode it instead.
        - As an example, you can hardcode `8371b4fb1155b71f4a04d3e1bc3e18c4a990aeeb` as the replication ID.
      - The offset is to be 0.

      These two values should be returned as part of the INFO command output, under the `master_replid` and `master_repl_offset` keys respectively.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh
      ```

      It'll then send the `INFO` command with `replication` as an argument to your server.

      ```bash
      $ redis-cli INFO replication
      ```

      Your program should respond with a [Bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings) where each line
      is a key value pair separated by `:`. The tester will look for the following keys:

      - `master_replid`, which should be a 40 character alphanumeric string
      - `master_repl_offset`, which should be `0`

      ### Notes

      - Your code should still pass the previous stage tests, so the `role` key still needs to be returned
    marketing_md: |
      In this stage, you'll add support for reading a key from an RDB file that contains a single key-value pair. You'll do this by implementing the `KEYS *` command.

  - slug: "repl-replica-ping"
    primary_extension_slug: "replication"
    name: "Send handshake (1/3)"
    difficulty: easy
    description_md: |
      In this stage, you'll implement part 1 of the handshake that happens when a replica connects to master.

      ### Handshake

      When a replica connects to a master, it needs to go through a handshake process before receiving updates from the master.

      There are three parts to this handshake:

      - The replica sends a `PING` to the master (**This stage**)
      - The replica sends `REPLCONF` twice to the master (Next stages)
      - The replica sends `PSYNC` to the master (Next stages)

      We'll learn more about `REPLCONF` and `PSYNC` in later stages. For now, we'll focus on the first part of the handshake: sending `PING` to the master.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT> --replicaof <MASTER_HOST> <MASTER_PORT>
      ```

      It'll then assert that the replica connects to the master and sends the `PING` command.

      ### Notes

      - The `PING` command should be sent as a RESP Array, like this : `*1\r\n$4\r\nPING\r\n`
    marketing_md: |
      In this stage, you'll add support for starting the handshake from the Replica side.

  - slug: "repl-replica-replconf"
    primary_extension_slug: "replication"
    name: "Send handshake (2/3)"
    difficulty: easy
    description_md: |
      In this stage, you'll implement part 2 of the handshake that happens when a replica connects to master.

      ### Handshake (continued from previous stage)

      As a recap, there are three parts to the handshake:

      - The replica sends a `PING` to the master (Previous stage)
      - The replica sends `REPLCONF` twice to the master (**This stage**)
      - The replica sends `PSYNC` to the master (Next stage)

      After receiving a response to `PING`, the replica then sends 2 [REPLCONF](https://redis.io/commands/replconf/) commands to the master.

      The `REPLCONF` command is used to configure replication. Replicas will send this command to the master twice:

      - The first time, it'll be sent like this: `REPLCONF listening-port <PORT>`
        - This is the replica notifying the master of the port it's listening on
      - The second time, it'll be sent like this: `REPLCONF capa psync2`
        - This is the replica notifying the master of its capabilities ("capa" is short for "capabilities")
        - You can safely hardcode these capabilities for now, we won't need to use them in this challenge.

      These commands should be sent as RESP Arrays, so the exact bytes will look something like this:

      ```
      # REPLCONF listening-port <PORT>
      *3\r\n$8\r\nREPLCONF\r\n$14\r\nlistening-port\r\n$4\r\n6380\r\n

      # REPLCONF capa psync2
      *3\r\n$8\r\nREPLCONF\r\n$4\r\ncapa\r\n$6\r\npsync2\r\n
      ```

      For both commands, the master will respond with `+OK\r\n` ("OK" encoded as a RESP Simple String).

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT> --replicaof <MASTER_HOST> <MASTER_PORT>
      ```

      It'll then assert that the replica connects to the master and:

      - **(a)** sends the `PING` command
      - **(b)** sends the `REPLCONF` command with `listening-port` and `<PORT>` as arguments
      - **(c)** sends the `REPLCONF` command with `capa psync2` as arguments

      **Notes**

      - The response to `REPLCONF` will always be `+OK\r\n` ("OK" encoded as a RESP Simple String)
    marketing_md: |
      In this stage, you'll add support for continuing the handshake from the Replica side, by sending REPLCONF.

  - slug: "repl-replica-psync"
    primary_extension_slug: "replication"
    name: "Send handshake (3/3)"
    difficulty: medium
    description_md: |
      In this stage, you'll implement part 3 of the handshake that happens when a replica connects to master.

      ### Handshake (continued from previous stage)

      As a recap, there are three parts to the handshake:

      - The replica sends a `PING` to the master (Previous stages)
      - The replica sends `REPLCONF` twice to the master (Previous stages)
      - The replica sends `PSYNC` to the master (**This stage**)

      After receiving a response to the second `REPLCONF`, the replica then sends a [PSYNC](https://redis.io/commands/psync/) command to the master.

      The `PSYNC` command is used to synchronize the state of the replica with the master. The replica will send this command to the master with two arguments:

      - The first argument is the replication ID of the master
        - Since this is the first time the replica is connecting to the master, the replication ID will be `?` (a question mark)
      - The second argument is the offset of the master
        - Since this is the first time the replica is connecting to the master, the offset will be `-1`

      So the final command sent will be `PSYNC ? -1`.

      This should be sent as a RESP Array, so the exact bytes will look something like this:

      ```
      *3\r\n$5\r\nPSYNC\r\n$1\r\n?\r\n$2\r\n-1\r\n
      ```

      The master will respond with a [Simple string](https://redis.io/docs/reference/protocol-spec/#simple-strings) that looks like this:

      ```
      +FULLRESYNC <REPL_ID> 0\r\n
      ```

      You can ignore the response for now, we'll get to handling it in later stages.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT> --replicaof <MASTER_HOST> <MASTER_PORT>
      ```

      It'll then assert that the replica connects to the master and:

      - **(a)** sends `PING` command
      - **(b)** sends `REPLCONF listening-port <PORT>`
      - **(c)** sends `REPLCONF capa eof capa psync2`
      - **(d)** sends `PSYNC ? -1`
    marketing_md: |
      In this stage, you'll add support for finishing the handshake from the Replica side, by sending PSYNC.

  - slug: "repl-master-replconf"
    primary_extension_slug: "replication"
    name: "Receive handshake (1/2)"
    difficulty: easy
    description_md: |
      In this stage, we'll start implementing support for receiving a replication handshake as a master.

      ### Handshake (continued from previous stage)

      We'll now implement the same handshake we did in the previous stages, but on the master instead of the replica.

      As a recap, there are three parts to the handshake:

      - The master receives a `PING` from the replica
        - Your Redis server already supports the `PING` command, so there's no additional work to do here
      - The master receives `REPLCONF` twice from the replica (**This stage**)
      - The master receives `PSYNC` from the replica (Next stage)

      In this stage, you'll add support for receiving the `REPLCONF` command from the replica.

      You'll receive `REPLCONF` twice from the replica. For the purposes of this challenge, you can safely ignore the arguments for both commands and just
      respond with `+OK\r\n` ("OK" encoded as a RESP Simple String).

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT>
      ```

      It'll then send the following commands:

      1. `PING` (expecting `+PONG\r\n` back)
      2. `REPLCONF listening-port <PORT>` (expecting `+OK\r\n` back)
      3. `REPLCONF capa eof capa psync2` (expecting `+OK\r\n` back)
    marketing_md: |
      In this stage, you'll add support for starting the handshake from the master side, by accepting REPLCONF.

  - slug: "repl-master-psync"
    primary_extension_slug: "replication"
    name: "Receive handshake (2/2)"
    difficulty: easy
    description_md: |
      In this stage, you'll add support for receiving the [`PSYNC`](https://redis.io/commands/psync/) command from the replica.

      ### Handshake (continued from previous stage)

      As a recap, there are three parts to the handshake:

      - The master receives a `PING` from the replica (You've already implemented this)
      - The master receives `REPLCONF` twice from the replica (You've already implemented this)
      - The master receives `PSYNC` from the replica (**This stage**)

      After the replica sends `REPLCONF` twice, it'll send a `PSYNC ? -1` command to the master.

      - The first argument is `?`
        - This is replication ID of the master, it is `?` because this is the first time the replica is connecting to the master.
      - The second argument is `-1`
        - This is the replication offset, it is `-1` because this is the first time the replica is connecting to the master.

      The final command you receive will look something like this:

      ```
      *3\r\n$5\r\nPSYNC\r\n$1\r\n?\r\n$2\r\n-1\r\n
      ```

      (That's `["PSYNC", "?", "-1"]` encoded as a RESP Array)

      The master needs to respond with `+FULLRESYNC <REPL_ID> 0\r\n` ("FULLRESYNC <REPL_ID> 0" encoded as a RESP Simple String). Here's what
      the response means:

      - `FULLRESYNC` means that the master cannot perform incremental replication with the replica, and will thus start a "full" resynchronization.
      - `<REPL_ID>` is the replication ID of the master. You've already set this in the "Replication ID & Offset" stage.
        - As an example, you can hardcode `8371b4fb1155b71f4a04d3e1bc3e18c4a990aeeb` as the replication ID.
      - `0` is the replication offset of the master. You've already set this in the "Replication ID & Offset" stage.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT>
      ```

      It'll then connect to your TCP server as a replica and execute the following commands:

      1. `PING` (expecting `+PONG\r\n` back)
      2. `REPLCONF listening-port <PORT>` (expecting `+OK\r\n` back)
      3. `REPLCONF capa eof capa psync2` (expecting `+OK\r\n` back)
      4. `PSYNC ? -1` (expecting `+FULLRESYNC <REPL_ID> 0\r\n` back)

      **Notes**:

      - In the response, `<REPL_ID>` needs to be replaced with the replication ID of the master which you've initialized in previous stages.
    marketing_md: |
      In this stage, you'll add support for accepting PSYNC, and starting a FULLRESYNC.

  - slug: "repl-master-psync-rdb"
    primary_extension_slug: "replication"
    name: "Empty RDB Transfer"
    difficulty: easy
    description_md: |
      In this stage, you'll add support for sending an empty RDB file to the replica. This is part of the "full resynchronization" process.

      ### Full resynchronization

      When a replica connects to a master for the first time, it sends a `PSYNC ? -1` command. This is the replica's way of
      telling the master that it doesn't have any data yet, and needs to be fully resynchronized.

      The master acknowledges this by sending a `FULLRESYNC` response to the replica.

      After sending the `FULLRESYNC` response, the master will then send a RDB file of its current state to the replica. The replica is expected to load the file into memory, replacing its current state.

      For the purposes of this challenge, you don't have to actually construct an RDB file. We'll assume that the master's database is always empty,
      and just hardcode an empty RDB file to send to the replica.

      You can find the hex representation of an empty RDB file [here](https://github.com/codecrafters-io/redis-tester/blob/main/internal/assets/empty_rdb_hex.md).

      The tester will accept any valid RDB file that is empty, you don't need to send the exact file above.

      The file is sent using the following format:

      ```
      $<length_of_file>\r\n<contents_of_file>
      ```

      (This is similar to how [Bulk Strings](https://redis.io/topics/protocol#resp-bulk-strings) are encoded, but without the trailing `\r\n`)

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT>
      ```

      It'll then connect to your TCP server as a replica and execute the following commands:

      1. `PING` (expecting `+PONG\r\n` back)
      2. `REPLCONF listening-port <PORT>` (expecting `+OK\r\n` back)
      3. `REPLCONF capa eof capa psync2` (expecting `+OK\r\n` back)
      4. `PSYNC ? -1` (expecting `+FULLRESYNC <REPL_ID> 0\r\n` back)

      After receiving a response to the last command, the tester will expect to receive an empty RDB file from your server.

      ### Notes

      - The [RDB file link](https://github.com/codecrafters-io/redis-tester/blob/main/internal/assets/empty_rdb_hex.md) contains hex & base64 representations
        of the file. You need to decode these into binary contents before sending it to the replica.
      - The RDB file should be sent like this: `$<length>\r\n<contents>`
        - `<length>` is the length of the file in bytes
        - `<contents>` is the contents of the file
        - Note that this is NOT a RESP bulk string, it doesn't contain a `\r\n` at the end
      - If you want to learn more about the RDB file format, read [this blog post](https://rdb.fnordig.de/file_format.html). This challenge
        has a separate extension dedicated to reading RDB files.
    marketing_md: |
      In this stage, you'll add support for sending an empty RDB file to the replica. This is part of the "full resynchronization" process.

  - slug: "repl-master-cmd-prop"
    primary_extension_slug: "replication"
    name: "Single-replica propagation"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for propagating write commands from a master to a single replica.

      ### Command propagation

      After the replication handshake is complete and the master has sent the RDB file to the replica, the
      master starts propagating commands to the replica.

      When a master receives a "write" command from a client, it propagates the command to the replica. The
      replica processes the command and updates its state. More on how this propagation works in the
      "Replication connection" section below.

      Commands like `PING`, `ECHO` etc. are not considered "write" commands, so they aren't propagated. Commands like
      `SET`, `DEL` etc. are considered "write" commands, so they are propagated.

      ### Replication connection

      Command propagation happens over the replication connection. This is the same connection that was used for the handshake.

      Propagated commands are sent as RESP arrays. For example, if the master receives `SET foo bar` as a command from a client,
      it'll send `*3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n` to all connected replicas over their respective replication connections.

      Replicas process commands received over the replication connection just like they would process commands received from a client,
      but with one difference: Replicas don't send responses back to the master. They just process the command silently and update their
      state.

      Similarly, the master doesn't wait for a response from the replica when propagating commands. It just keeps sending commands as they
      come in.

      There is one exception to this "no response" rule, the `REPLCONF GETACK` command. We'll learn about this in later stages.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT>
      ```

      It'll then connect to your TCP server as a replica and execute the following commands:

      1. `PING` (expecting `+PONG\r\n` back)
      2. `REPLCONF listening-port <PORT>` (expecting `+OK\r\n` back)
      3. `REPLCONF capa eof capa psync2` (expecting `+OK\r\n` back)
      4. `PSYNC ? -1` (expecting `+FULLRESYNC <REPL_ID> 0\r\n` back)

      The tester will then wait for your server to send an RDB file.

      Once the RDB file is received, the tester will send series of write commands to your program (as a separate Redis client, not the replica).

      ```bash
      $ redis-cli SET foo 1
      $ redis-cli SET bar 2
      $ redis-cli SET baz 3
      ```

      It'll then assert that these commands were propagated to the replica, in order. The tester will
      expect to receive these commands (encoded as RESP arrays) on the replication connection (the one used for the handshake).

      ### Notes

      - A true implementation would buffer the commands so that they can be sent to the replica after it loads the RDB file. For the
        purposes of this challenge, you can assume that the replica is ready to receive commands immediately after receiving the RDB file.
    marketing_md: |
      In this stage, you'll add support for finishing the sync handshake from the master side, by sending a RDB file.

  - slug: "repl-multiple-replicas"
    primary_extension_slug: "replication"
    name: "Multi Replica Command Propagation"
    difficulty: hard
    description_md: |
      In this stage, you'll extend your implementation to support propagating commands to multiple replicas.

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT>
      ```

      It'll then start **multiple** replicas that connect to your server and execute the following commands:

      1. `PING` (expecting `+PONG\r\n` back)
      2. `REPLCONF listening-port <PORT>` (expecting `+OK\r\n` back)
      3. `REPLCONF capa psync2` (expecting `+OK\r\n` back)
      4. `PSYNC ? -1` (expecting `+FULLRESYNC <REPL_ID> 0\r\n` back)

      Each replica will expect to receive an RDB file from the master after the handshake is complete.

      It'll then send `SET` commands to the master from a client (a separate Redis client, not the replicas).

      ```bash
      $ redis-cli SET foo 1
      $ redis-cli SET bar 2
      $ redis-cli SET baz 3
      ```

      It'll then assert that each replica received those commands, in order.
    marketing_md: |
      In this stage, you'll complete your implementation of Redis replication.

  - slug: "repl-cmd-processing"
    primary_extension_slug: "replication"
    name: "Command Processing"
    difficulty: hard
    description_md: |
      In this stage you'll implement the processing of commands propagated to the replica from the master.

      ### Command processing

      After the replica receives a command from the master, it processes it and apply it to its own state. This
      will work exactly like a regular command sent by a client, except that the replica doesn't send a response
      back to the master.

      For example, if the command `SET foo 1` is propagated to the replica by a master, the replica must update
      its database to set the value of `foo` to `1`. Unlike commands from a regular client though, it must not reply with `+OK\r\n`.

      ### Tests

      The tester will spawn a Redis master, and it'll then execute your program as a replica like this:

      ```
      ./spawn_redis_server.sh --port <PORT> --replicaof <MASTER_HOST> <MASTER_PORT>
      ```

      Just like in the previous stages, your replica should complete the handshake with the master and receive an empty RDB file.

      Once the RDB file is received, the master will propagate a series of write commands to your program.

      ```bash
      SET foo 1 # propagated from master to replica
      SET bar 2 # propagated from master to replica
      SET baz 3 # propagated from master to replica
      ```

      The tester will then issue `GET` commands to your program to check if the commands were processed correctly.

      ```bash
      $ redis-cli GET foo # expecting `1` back
      $ redis-cli GET bar # expecting `2` back
      # ... and so on
      ```

      ### Notes

      - The propagated commands are sent as RESP arrays. So the command `SET foo 1` will be sent as `*3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$1\r\n1\r\n`.
      - It is **not** guaranteed that propagated commands will be sent one at a time. One "TCP segment" might contain bytes for multiple commands.
    marketing_md: |
      In this stage, you'll add support for processing commands received by the replica from the master.

  - slug: "repl-replica-getack"
    primary_extension_slug: "replication"
    name: "ACKs with no commands"
    difficulty: easy
    description_md: |
      In this stage you'll implement support for the `REPLCONF GETACK` command that a master sends a replica.

      ### ACKs

      <details>
        <summary>Click to expand/collapse</summary>

        Unlike regular commands, when a master forwards commands to a replica via the replication connection, the replica doesn't
        respond to each command. It just silently processes the commands and updates its state.

        Since the master doesn't receive a response for each command, it needs another way to keep track of whether a replica is "in sync".
        That's what ACKs are for.

        ACK is short for "acknowledgement". Redis masters periodically ask replicas to send ACKs.

        Each ACK contains an "offset", which is the number of bytes of commands processed by the replica.

        We'll learn about how this offset is calculated and used in later stages. In this stage, we'll focus on implementing the
        mechanism through which a master asks for an ACK from a replica: the `REPLCONF GETACK` command.
      </details>

      ### The `REPLCONF GETACK` command

      <details>
        <summary>Click to expand/collapse</summary>

        When a master requires an ACK from a replica, it sends a `REPLCONF GETACK *` command to the replica. This is sent over
        the replication connection (i.e. the connection that remains after the replication handshake is complete).

        When the replica receives this command, it responds with a `REPLCONF ACK <offset>` response. The offset is the
        number of bytes of commands processed by the replica. It starts at 0 and is incremented for every command processed by the replica.

        In this stage, you'll implement support for receiving the `REPLCONF GETACK *` command and responding with `REPLCONF ACK 0`.

        You can hardcode the offset to 0 for now. We'll implement proper offset tracking in the next stage.

        The exact command received by the replica will look something like this: `*3\r\n$8\r\nreplconf\r\n$6\r\ngetack\r\n$1\r\n*\r\n` (that's
        `["replconf", "getack", "*"]` encoded as a [RESP Array](https://redis.io/docs/reference/protocol-spec/#arrays)).
      </details>

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT> --replicaof <HOST> <PORT>
      ```

      Just like in the previous stages, your replica should complete the handshake with the master and receive an empty RDB file.

      The master will then send `REPLCONF GETACK *` to your replica. It'll expect to receive `REPLCONF ACK 0` as a reply.

      ### Notes

      - The response should be encoded as a [RESP Array](https://redis.io/docs/reference/protocol-spec/#arrays), like
        this: `*3\r\n$8\r\nREPLCONF\r\n$3\r\nACK\r\n$1\r\n0\r\n`.
      - We'll implement proper offset tracking in the next stage, for now you can hardcode the offset to 0.
      - After the master-replica handshake is complete, a replica should **only** send responses to `REPLCONF GETACK` commands. All
        other propagated commands (like `PING`, `SET` etc.) should be read and processed, but a response should not be sent back to the master.
    marketing_md: |
      In this stage, you'll add support for returning an ACK back to master as a response to GETACK.

  - slug: "repl-replica-getack-nonzero"
    primary_extension_slug: "replication"
    name: "ACKs with commands"
    difficulty: medium
    description_md: |
      In this stage, you'll extend your `REPLCONF GETACK` implementation to respond with the number of bytes of commands processed by the replica.

      ### Offset tracking

      <details>
        <summary>Click to expand/collapse</summary>
        As we saw in previous stages, when a replica receives a command from the master, it processes it and updates its state. In addition to processing
        commands, the replica also keeps a running count of the number of bytes of commands it has processed.

        This count is called the "offset". When a master sends a `REPLCONF GETACK` command to a replica, the replica is expected to respond with
        `REPLCONF ACK <offset>`. The returned `<offset>` should only include the number of bytes of commands processed **before** receiving the `REPLCONF GETACK` command.

        As an example:

        - Let's say a replica connects to a master and completes the handshake.
        - The master then sends a `REPLCONF GETACK *` command.
            - The replica should respond with `REPLCONF ACK 0`.
            - The returned offset is 0 since no commands have been processed yet (before receiving the `REPLCONF GETACK` command)
        - The master then sends `REPLCONF GETACK *` again.
            - The replica should respond with `REPLCONF ACK 37`.
            - The returned offset is 37 since the first `REPLCONF GETACK` command was processed, and it was 37 bytes long.
            - The RESP encoding for the `REPLCONF GETACK` command looks like this: ``*3\r\n$8\r\nreplconf\r\n$6\r\ngetack\r\n$1\r\n*\r\n` (that's 37 bytes long)
        - The master then sends a `PING` command to the replica (masters do this periodically to notify replicas that the master is still alive).
            - The replica must silently process the `PING` command and update its offset. It should not send a response back to the master.
        - The master then sends `REPLCONF GETACK *` again (this is the third REPLCONF GETACK command received by the replica)
            - The replica should respond with `REPLCONF ACK 88`.
            - The returned offset is 88 (37 + 37 + 14)
                - 37 for the first `REPLCONF GETACK` command
                - 37 for the second `REPLCONF GETACK` command
                - 14 for the `PING` command
            - Note that the third `REPLCONF GETACK` command is not included in the offset, since the value should
            only include the number of bytes of commands processed **before** receiving the current `REPLCONF GETACK` command.
        - ... and so on

      </details>

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh --port <PORT> --replicaof <HOST> <PORT>
      ```

      Just like in the previous stages, your replica should complete the handshake with the master and receive an empty RDB file.

      The master will then propagate a series of commands to your replica. These commands will be interleaved with `REPLCONF GETACK *` commands.

      ```bash
      REPLCONF getack * # expecting REPLCONF ACK 0, since 0 bytes have been processed

      ping # master sending a ping command to notify the replica that it's still alive
      REPLCONF getack * # expecting REPLCONF ACK 51 (37 for the first REPLCONF command + 14 for the ping command)

      set foo 1 # propagated from master to replica
      set bar 2 # propagated from master to replica
      REPLCONF getack * # expecting REPLCONF ACK 109 (51 + 29 for the first set command + 29 for the second set command)
      ```

      ### Notes

      - The offset should only include the number of bytes of commands processed **before** receiving the current `REPLCONF GETACK` command.
      - Although masters don't propagate `PING` commands when received from clients (since they aren't "write" commands),
        they may send `PING` commands to replicas to notify replicas that the master is still alive.
      - Replicas should update their offset to account for **all** commands propagated from the master, including `PING` and `REPLCONF` itself.
      - The response should be encoded as a [RESP Array](https://redis.io/docs/reference/protocol-spec/#arrays), like
        this: `*3\r\n$8\r\nREPLCONF\r\n$3\r\nACK\r\n$3\r\n154\r\n`.
    marketing_md: |
      In this stage, you'll add support for returning an ACK back to master as a response to GETACK.

  - slug: "repl-wait-zero-replicas"
    primary_extension_slug: "replication"
    name: "WAIT with no replicas"
    difficulty: medium
    description_md: |
      **🚧 We're still working on instructions for this stage**. You can find notes on how the tester works below.

      <!--
      In the next 3 stages, you will implement the WAIT command on your master.
      The WAIT command is used to find out how many replicas a write command was propagated to, with the replica ACKing it back. This way we can know how durable the write was. As we haven't implemented periodic ACKs from the replica, in this stage, for WAIT, the master has to send a GETACK to the replica, if the replica replies back with the proper offset, before the WAIT expires, the master can count that replica's write to be a success.

      In this stage you will implement WAIT, when exactly 0 replicas are connected to Master. The Master can just return 0 asap. This way we will gently dive into the implementation.
      -->

      ### Tests

      The tester will execute your program like this:

      ```
      ./spawn_redis_server.sh
      ```

      A redis client will then connect to your master and send `WAIT 0 60000`:

      ```bash
      $ redis-cli WAIT 0 60000
      ```

      It'll expect to receive `0` back immediately, since no replicas are connected.

      ### Notes

      - You can hardcode `0` as the response for the WAIT command in this stage. We'll get to tracking the number of replicas and responding
        accordingly in the next stages.
    marketing_md: |
      In this stage, you'll start implementing the WAIT command on your master.

  - slug: "repl-wait-zero-offset"
    primary_extension_slug: "replication"
    name: "WAIT with no commands"
    difficulty: medium
    description_md: |
      **🚧 We're still working on instructions for this stage**. You can find notes on how the tester works below.

      <!--

      In this stage you will implement WAIT, when some replicas are connected to Master, but there have been NO commands propagated from master to replica. So offset is essentially 0. In this case, the Master can just return the count of `connected_slaves` asap.  (The replicas will finish the sync handshake with Master, so they are actually connnected.)
      (The master will return the count of `connected_slaves` no matter how many replicas we pass in the WAIT command parameter. As the offset is 0, it knows all replicas are in sync.)

      -->

      ### Tests

      The tester will execute your program as a master like this:

      ```
      ./spawn_redis_server.sh
      ```

      It'll then start **multiple** replicas that connect to your server. Each will complete the handshake and expect to receive an empty RDB file.

      It'll then connect to your master as a Redis client (not one of the replicas) and send commands like this:

      ```bash
      $ redis-cli WAIT 3 500 # (expecting 7 back)
      $ redis-cli WAIT 7 500 # (expecting 7 back)
      $ redis-cli WAIT 9 500 # (expecting 7 back)
      ```

      The response to each of these commands should be encoded as a RESP integer (i.e. `:7\r\n`).

      ### Notes

      - Even if WAIT is called with a number lesser than the number of connected replicas, the master should return the count of connected replicas.
      - The number of replicas created in this stage will be random, so you can't hardcode `7` as the response like in the example above.
    marketing_md: |
      In this stage, you'll continue implementing the WAIT command on your master.

  - slug: "repl-wait"
    primary_extension_slug: "replication"
    name: "WAIT with multiple commands"
    difficulty: hard
    description_md: |
      **🚧 We're still working on instructions for this stage**. You can find notes on how the tester works below.

      <!--
      In this stage you will implement WAIT, when some replicas are connected to Master, and there have been commands propagated from master to replica. So the offset is NOT 0. In this case, the Master has to figure out how many replicas the previous write command has been successfully propagated to.
      (The replicas will finish the sync handshake with Master, and process any commands you send it, but they WON'T send periodic ACKs, so you need to basically send a REPLCONF GETACK to get their current offset. )
      -->

      ### Tests

      The tester will execute your program as a master like this:

      ```
      ./spawn_redis_server.sh
      ```

      It'll then start **multiple** replicas that connect to your server. Each will complete the handshake and expect to receive an empty RDB file.

      The tester will then connect to your master as a Redis client (not one of the replicas) and send multiple write commands interleaved
      with `WAIT` commands:

      ```bash
      $ redis-cli SET foo 123
      $ redis-cli WAIT 1 500 # (must wait until either 1 replica has processed previous commands or 500ms have passed)

      $ redis-cli SET bar 456
      $ redis-cli WAIT 2 500 # (must wait until either 2 replicas have processed previous commands or 500ms have passed)
      ```

      ### Notes

      - The `WAIT` command should return when either (a) the specified number of replicas have acknowledged the command, or (b) the timeout expires.
      - The `WAIT` command should always return the number of replicas that have acknowledged the command, even if the timeout expires.
      - The returned number of replicas might be lesser than or greater than the expected number of replicas specified in the `WAIT` command.
    marketing_md: |
      In this stage, you'll finish implementing the WAIT command on your master.

  # Streams
  - slug: "streams-type"
    primary_extension_slug: "streams"
    name: "The TYPE command"
    difficulty: easy
    description_md: |
      In this stage, you'll add support for the `TYPE` command.

      ### The TYPE command

      The [TYPE](https://redis.io/commands/type/) command returns the type of value stored at a given key.

      It returns one of the following types: string, list, set, zset, hash, and stream.

      Here's how it works:

      ```bash
      $ redis-cli SET some_key foo
      "OK"
      $ redis-cli TYPE some_key
      "string"
      ```

      If a key doesn't exist, the return value will be "none".

      ```bash
      $ redis-cli TYPE missing_key
      "none"
      ```

      The return value is encoded as a [simple string](https://redis.io/docs/reference/protocol-spec/#simple-strings).

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then send a `SET` command to your server.

      ```bash
      $ redis-cli SET some_key foo
      ```

      It'll then send a `TYPE` command to your server.

      ```bash
      $ redis-cli TYPE some_key
      ```

      Your server should respond with `+string\r\n`, which is `string` encoded as a [RESP simple string](https://redis.io/docs/reference/protocol-spec/#simple-strings).

      It'll then send another `TYPE` command with a missing key.

      ```bash
      $ redis-cli TYPE missing_key
      ```

      Your server should respond with `+none\r\n`, which is `none` encoded as a [RESP simple string](https://redis.io/docs/reference/protocol-spec/#simple-strings).

      ### Notes

      - For now, you only need to handle the "string" and "none" types. We'll add support for the "stream" type in the next stage.
    marketing_md: |
      In this stage, you'll add support for the `TYPE` command.

  - slug: "streams-xadd"
    primary_extension_slug: "streams"
    name: "Create a stream"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for creating a [Redis stream](https://redis.io/docs/data-types/streams/) using the `XADD` command.

      ### Redis Streams & Entries

      Streams are one of the data types that Redis supports. A stream is identified by a key, and it contains multiple entries.

      Each entry consists of one or more key-value pairs, and is assigned a unique ID.

      For example, if you were using a Redis stream to store real-time data from a temperature & humidity monitor, the contents of the stream might look like this:

      ```yaml
      entries:
        - id: 1526985054069-0 # (ID of the first entry)
          temperature: 36 # (A key value pair in the first entry)
          humidity: 95 # (Another key value pair in the first entry)

        - id: 1526985054079-0 # (ID of the second entry)
          temperature: 37 # (A key value pair in the first entry)
          humidity: 94 # (Another key value pair in the first entry)

        # ... (and so on)
      ```

      We'll take a closer look at the format of entry IDs (`1526985054069-0` and `1526985054079-0` in the example above) in the upcoming stages.

      ### The XADD command

      The [XADD](https://redis.io/commands/xadd/) command appends an entry to a stream. If a stream doesn't exist already, it is created.

      Here's how it works:

      ```bash
      $ redis-cli XADD stream_key 1526919030474-0 temperature 36 humidity 95
      "1526919030474-0" # (ID of the entry created)
      ```

      The return value is the ID of the entry created, encoded as a [bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings).

      `XADD` supports other optional arguments, but we won't deal with them in this challenge.

      `XADD` also supports auto-generating entry IDs. We'll add support for that in later stages. For now, we'll only deal with
      explicit IDs (like `1526919030474-0` in the example above).

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then send an `XADD` command to your server and expect the ID as a response.

      ```bash
      $ redis-cli XADD stream_key 0-1 foo bar
      "0-1"
      ```

      Your server should respond with `$3\r\n0-1\r\n`, which is `0-1` encoded as a [RESP bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings).

      The tester will then send a `TYPE` command to your server.

      ```bash
      $ redis-cli TYPE stream_key
      "stream"
      ```

      Your server should respond with `+stream\r\n`, which is `stream` encoded as a [RESP simple string](https://redis.io/docs/reference/protocol-spec/#simple-strings).

      ### Notes

      - You still need to handle the "string" and "none" return values for the `TYPE` command. "stream" should only be returned for keys that are streams.
    marketing_md: |
      In this stage, you'll add support for creating a [Redis stream](https://redis.io/docs/data-types/streams/) using the `XADD` command.

  - slug: "streams-xadd-validate-id"
    primary_extension_slug: "streams"
    name: "Validating entry IDs"
    difficulty: easy
    description_md: |
      In this stage, you'll add support for validating entry IDs to the `XADD` command.

      ### Entry IDs

      Here's an example of stream entries from the previous stage:

      ```yaml
      entries:
        - id: 1526985054069-0 # (ID of the first entry)
          temperature: 36 # (A key value pair in the first entry)
          humidity: 95 # (Another key value pair in the first entry)

        - id: 1526985054079-0 # (ID of the second entry)
          temperature: 37 # (A key value pair in the first entry)
          humidity: 94 # (Another key value pair in the first entry)

        # ... (and so on)
      ```

      Entry IDs are always composed of two integers: `<millisecondsTime>-<sequenceNumber>`.

      Entry IDs are unique within a stream, and they're guaranteed to be incremental - i.e. an
      entry added later will always have an ID greater than an entry added in the past. More
      on this in the next section.

      ### Specifying entry IDs in XADD

      There are multiple formats in which the ID can be specified in the XADD command:

      - Explicit ("1526919030474-0") (**This stage**)
      - Auto-generate only sequence number ("1526919030474-*") (Next stages)
      - Auto-generate time part and sequence number ("*") (Next stages)

      In this stage, we'll only deal with explicit IDs. We'll add support for the other two cases in the next stages.

      Your XADD implementation should validate the ID passed in.

      - The ID should be greater than the ID of the last entry in the stream.
        - The `millisecondsTime` part of the ID should be greater than or equal to the `millisecondsTime` of the last entry.
        - If the `millisecondsTime` part of the ID is equal to the `millisecondsTime` of the last entry, the `sequenceNumber` part of the ID should be greater than the `sequenceNumber` of the last entry.
      - If the stream is empty, the ID should be greater than `0-0`

      Here's an example of adding an entry with a valid ID followed by an invalid ID:

      ```bash
      $ redis-cli XADD some_key 1-1 foo bar
      "1-1"
      $ redis-cli XADD some_key 1-1 bar baz
      (error) ERR The ID specified in XADD is equal or smaller than the target stream top item
      ```

      Here's another such example:

      ```bash
      $ redis-cli XADD some_key 1-1 foo bar
      "1-1"
      $ redis-cli XADD some_key 0-2 bar baz
      (error) ERR The ID specified in XADD is equal or smaller than the target stream top item
      ```

      The minimum entry ID that Redis supports is 0-1. Passing in an ID lower than should result in an error.

      ```bash
      $ redis-cli XADD some_key 0-0 bar baz
      (error) ERR The ID specified in XADD must be greater than 0-0
      ```

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll create a few entries usind `XADD`.

      ```bash
      $ redis-cli XADD stream_key 1-1 foo bar
      "1-1"
      $ redis-cli XADD stream_key 1-2 bar baz
      "1-2"
      ```

      It'll send another `XADD` command with the same time and sequence number as the last entry.

      ```bash
      $ redis-cli XADD stream_key 1-2 baz foo
      (error) ERR The ID specified in XADD is equal or smaller than the target stream top item
      ```

      Your server should respond with "-ERR The ID specified in XADD is equal or smaller than the target stream top item\r\n", which is the error message above encoded as a
      [simple error](https://redis.io/docs/reference/protocol-spec/#simple-errors).

      The tester will then send another `XADD` command with a smaller value for the time and a larger value for the sequence number.

      ```bash
      $ redis-cli XADD stream_key 0-3 baz foo
      (error) ERR The ID specified in XADD is equal or smaller than the target stream top item
      ```

      Your server should also respond with the same error message.

      After that, the tester will send another `XADD` command with `0-0` as the ID.

      ```bash
      $ redis-cli XADD stream_key 0-0 baz foo
      ```

      Your server should respond with "-ERR The ID specified in XADD must be greater than 0-0\r\n", which is the error message above encoded as a
      [RESP simple error](https://redis.io/docs/reference/protocol-spec/#simple-errors).
    marketing_md: |
      In this stage, you'll enhance the `XADD` command by extending support for explicit IDs.

  - slug: "streams-xadd-partial-autoid"
    primary_extension_slug: "streams"
    name: "Partially auto-generated IDs"
    difficulty: medium
    description_md: |
      In this stage, you'll extend your `XADD` command implementation to support auto-generating the
      sequence number part of the entry ID.

      ### Specifying entry IDs in XADD

      As a recap, there are multiple formats in which the ID can be specified in the `XADD` command:

      - Explicit ("1526919030473-0") (Previous stage)
      - Auto-generate only sequence number ("1526919030474-*") (**This stage**)
      - Auto-generate time part and sequence number ("*") (Next stage)

      We dealt with explicit IDs in the last stage. We'll handle the second case in this stage.

      When `*` is used for the sequence number, Redis picks the last sequence number used in the
      stream (for the same time part) and increments it by 1.

      The default sequence number is 0. The only exception is when the time part is also 0. In that case, the default sequence number is 1.

      Here's an example of adding an entry with `*` as the sequence number:

      ```bash
      $ redis-cli XADD some_key "1-*" foo bar
      "1-0" # If there are no entries, the sequence number will be 0
      $ redis-cli XADD some_key "1-*" bar baz
      "1-1" # Adding another entry will increment the sequence number
      ```

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll send an `XADD` command with `*` as the sequence number.

      ```bash
      $ redis-cli XADD stream_key 0-* foo bar
      ```

      Your server should respond with `$3\r\n0-1\r\n`, which is `0-1` encoded as a RESP bulk string.

      It'll then send another `XADD` command with `*` as the sequence number, but this time with a
      random number as the time part.

      ```bash
      $ redis-cli XADD stream_key 5-* foo bar
      ```

      Your server should respond with `$3\r\n5-0\r\n`, which is `5-0` encoded as a [RESP bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings)

      It'll send the same command again.

      ```bash
      $ redis-cli XADD stream_key 5-* bar baz
      ```

      Your server should respond with `$3\r\n5-1\r\n`, which is `5-1` encoded as a [RESP bulk string](https://redis.io/docs/reference/protocol-spec/#bulk-strings)

      ### Notes

      - The tester will use a random number for the time part (we use `5` in the example above).
    marketing_md: |
      In this stage, you'll enhance the `XADD` command by adding the option to use `*` as the sequence number.

  - slug: "streams-xadd-full-autoid"
    primary_extension_slug: "streams"
    name: "Fully auto-generated IDs"
    difficulty: medium
    description_md: |
      In this stage, you'll extend your `XADD` command implementation to support auto-generating entry IDs.

      ### Specifying entry IDs in XADD (Continued...)

      As a recap, there are multiple formats in which the ID can be specified in the `XADD` command:

      - Explicit ("1526919030474-0") (Previous stages)
      - Auto-generate only sequence number ("1526919030473-*") (Previous stages)
      - Auto-generate time part and sequence number ("*") (**This stage**)

      We'll now handle the third case.

      When `*` is used with the `XADD` command, Redis auto-generates a unique auto-incrementing ID for the message being appended to the stream.

      Redis defaults to using the current unix time in milliseconds for the time part and 0 for the sequence number. If the
      time already exists in the stream, the sequence number for that record incremented by one will be used.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then create an entry with `*` as the ID.

      ```bash
      $ redis-cli XADD stream_key * foo bar
      ```

      Your server should respond with a string like `$15\r\n1526919030474-0\r\n`, which is `1526919030474-0` encoded as a RESP bulk string.

      ### Notes

      - The time part of the ID should be the current unix time in **milliseconds**, not seconds.
      - The tester doesn't test the case where a time part already exists in the stream and the sequence
        number is incremented. This is difficult to test reliably since we'd need to send 2 commands within the same millisecond.
    marketing_md: |
      In this stage, you'll enhance the `XADD` command by adding the option to use `*` as the entry ID.

  - slug: "streams-xrange"
    primary_extension_slug: "streams"
    name: "Query entries from stream"
    difficulty: medium
    description_md: |
      In this stage, you'll add support for querying data from a stream using the `XRANGE` command.

      ### The XRANGE command

      The [XRANGE](https://redis.io/commands/xrange/) command retrieves a range of entries from a stream.

      It takes two arguments: `start` and `end`. Both are entry IDs. The command returns all entries in the
      stream with IDs between the `start` and `end` IDs. This range is "inclusive", which means that the response
      will includes entries with IDs that are equal to the `start` and `end` IDs.

      Here's an example of how it works:

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0" # (ID of the first added entry)
      $ redis-cli XADD some_key 1526985054079-0 temperature 37 humidity 94
      "1526985054079-0"
      $ redis-cli XRANGE some_key 1526985054069 1526985054079
      1) 1) 1526985054069-0
         2) 1) temperature
            2) 36
            3) humidity
            4) 95
      2) 1) 1526985054079-0
         2) 1) temperature
            2) 37
            3) humidity
            4) 94
      ```

      The sequence number doesn't need to be included in the start and end IDs provided to the command. If not provided,
      XRANGE defaults to a sequence number of 0 for the start and the maximum sequence number for the end.

      The return value of the command is not exactly what is shown in the example above. This is already formatted by redis-cli.

      The actual return value is a [RESP Array](https://redis.io/docs/reference/protocol-spec/#arrays) of arrays.

      - Each inner array represents an entry.
      - The first item in the inner array is the ID of the entry.
      - The second item is a list of key value pairs, where the key value pairs are represented as a list of strings.
        - The key value pairs are in the order they were added to the entry.

      The return value of the example above is actually something like this:

      ```json
      [
        [
          "1526985054069-0",
          [
            "temperature",
            "36",
            "humidity",
            "95"
          ]
        ],
        [
          "1526985054079-0",
          [
            "temperature",
            "37",
            "humidity",
            "94"
          ]
        ],
      ]
      ```

      When encoded as a RESP list, it looks like this:

      ```text
      *2\r\n
      *2\r\n
      $15\r\n1526985054069-0\r\n
      *4\r\n
      $11\r\ntemperature\r\n
      $2\r\n36\r\n
      $8\r\nhumidity\r\n
      $2\r\n95\r\n
      *2\r\n
      $15\r\n1526985054079-0\r\n
      *4\r\n
      $11\r\ntemperature\r\n
      $2\r\n37\r\n
      $8\r\nhumidity\r\n
      $2\r\n94\r\n
      ```

      In the code block above, the response is separated into multiple lines for readability. The actual
      return value doesn't contain any additional newlines.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      First, it'll add a few entries.

      ```bash
      $ redis-cli XADD stream_key 0-1 foo bar
      "0-1"
      $ redis-cli XADD stream_key 0-2 bar baz
      "0-2"
      $ redis-cli XADD stream_key 0-3 baz foo
      "0-3"
      ```

      Then, it'll send an `XRANGE` command to your server.

      ```bash
      $ redis-cli XRANGE stream_key 0-2 0-3
      ```

      Your server should respond with the following (encoded as a RESP Array):

      ```json
      [
        [
          "0-2",
          [
            "bar",
            "baz"
          ]
        ],
        [
          "0-3",
          [
            "baz",
            "foo"
          ]
        ]
      ]
      ```
    marketing_md: |
      In this stage, you'll add support for querying data from a stream using the `XRANGE` command.

  - slug: "streams-xrange-min-id"
    primary_extension_slug: "streams"
    name: "Query with -"
    difficulty: easy
    description_md: |
      In this stage, you'll extend support for `XRANGE` to allow querying using `-`.

      ### Using XRANGE with -

      In the previous stage, we saw that `XRANGE` takes `start` and `end` as arguments.

      In addition to accepting an explicit entry ID, `start` can also be specified as `-`. When `-` is used, `XRANGE` retrieves entries from the beginning of the stream.

      Here's an example of how that works.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XADD some_key 1526985054079-0 temperature 37 humidity 94
      "1526985054079-0"
      $ redis-cli XRANGE some_key - 1526985054079
      1) 1) 1526985054069-0
         2) 1) temperature
            2) 36
            3) humidity
            4) 95
      2) 1) 1526985054079-0
         2) 1) temperature
            2) 37
            3) humidity
            4) 94
      ```

      In the example above, `XRANGE` retrieves all entries from the beginning of the stream to the entry with ID `1526985054079-0`.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then create a few entries.

      ```bash
      $ redis-cli XADD stream_key 0-1 foo bar
      "0-1"
      $ redis-cli XADD stream_key 0-2 bar baz
      "0-2"
      $ redis-cli XADD stream_key 0-3 baz foo
      "0-3"
      ```

      It'll then send an `XRANGE` command to your server.

      ```bash
      $ redis-cli XRANGE stream_key - 0-2
      1) 1) 0-1
         2) 1) foo
            2) bar
      2) 1) 0-2
         2) 1) bar
            2) baz
      ```

      Your server should respond with the following, encoded as a [RESP Array](https://redis.io/docs/reference/protocol-spec/#arrays):

      ```json
      [
        [
          "0-1",
          [
            "foo",
            "bar"
          ]
        ],
        [
          "0-2",
          [
            "bar",
            "baz"
          ]
        ]
      ]
      ```
    marketing_md: |
      In this stage, you'll extend support for `XRANGE` to allow querying using `-`.

  - slug: "streams-xrange-max-id"
    primary_extension_slug: "streams"
    name: "Query with +"
    difficulty: easy
    description_md: |
      In this stage, you'll extend support for `XRANGE` to allow querying using `+`.

      ### Using XRANGE with +

      In the previous stage, we saw that `XRANGE` takes `start` and `end` as arguments.

      In addition to accepting an explicit entry ID, `end` can also be specified as `+`. When `+` is used, `XRANGE` retrieves entries until the end of the stream.

      Here's an example of how that works.

      We'll use our previous example for entries existing in a stream.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XADD some_key 1526985054079-0 temperature 37 humidity 94
      "1526985054079-0"
      $ redis-cli XRANGE some_key 1526985054069 +
      1) 1) 1526985054069-0
         2) 1) temperature
            2) 36
            3) humidity
            4) 95
      2) 1) 1526985054079-0
         2) 1) temperature
            2) 37
            3) humidity
            4) 94
      ```

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      It'll then create a few entries.

      ```bash
      $ redis-cli XADD stream_key 0-1 foo bar
      $ redis-cli XADD stream_key 0-2 bar baz
      $ redis-cli XADD stream_key 0-3 baz foo
      ```

      It'll then send an `XRANGE` command to your server.

      ```bash
      $ redis-cli XRANGE stream_key 0-2 +
      ```

      Your server should respond with the following:

      ```text
      *2\r\n
      *2\r\n
      $3\r\n0-2\r\n
      *2\r\n
      $3\r\nbar\r\n
      $3\r\nbaz\r\n
      *2\r\n
      $3\r\n0-3\r\n
      *2\r\n
      $3\r\nbaz\r\n
      $3\r\nfoo\r\n
      ```

      This is the RESP encoded representation of the following.

      ```json
      [
        [
          "0-2",
          [
            "bar",
            "baz"
          ]
        ],
        [
          "0-3",
          [
            "baz",
            "foo"
          ]
        ]
      ]
      ```

      ### Notes
      - In the response, the items are separated onto new lines for readability. The tester expects all of these to be in one line.
    marketing_md: |
      In this stage, you'll extend support for `XRANGE` to allow querying using `+`.

  - slug: "streams-xread"
    primary_extension_slug: "streams"
    name: "Query single stream using XREAD"
    difficulty: medium
    description_md: |
      In this stage, you'll add support to querying a stream using the `XREAD` command.

      ### The XREAD command

      [XREAD](https://redis.io/commands/xread/) is used to read data from one or more streams, starting from a specified entry ID.

      Here's how it works.

      Let's use the entries previously shown as an example.

      ```yaml
      entries:
        - id: 1526985054069-0 # (ID of the first entry)
          temperature: 36 # (A key value pair in the first entry)
          humidity: 95 # (Another key value pair in the first entry)

        - id: 1526985054079-0 # (ID of the second entry)
          temperature: 37 # (A key value pair in the first entry)
          humidity: 94 # (Another key value pair in the first entry)

        # ... (and so on)
      ```

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XADD some_key 1526985054079-0 temperature 37 humidity 94
      "1526985054079-0"
      $ redis-cli XREAD streams some_key 1526985054069-0
      1) 1) "some_key"
         2) 1) 1) 1526985054079-0
               2) 1) temperature
                  2) 37
                  3) humidity
                  4) 94
      ```

      `XREAD` is somewhat similar to `XRANGE`. The primary difference is that `XREAD` only takes a single argument and not a start-end pair.

      Another difference is that `XREAD` is exclusive. This means that only entries with the ID greater than what was provided will be included in the response.

      Another difference is the return type. `XREAD` returns an array where each element is an array composed of two elements, which are the ID and the list of fields and values.

      Here's what the response in the example above actually looks like:

      ```json
      [
        [
          "some_key",
          [
            [
              "1526985054079-0",
              [
                "temperature",
                "37",
                "humidity",
                "94"
              ]
            ]
          ]
        ]
      ]
      ```

      When encoded as RESP, it looks like this:

      ```text
      *1\r\n
      *2\r\n
      $8\r\nsome_key\r\n
      *1\r\n
      *2\r\n
      $15\r\n1526985054079-0\r\n
      *4\r\n
      $11\r\ntemperature\r\n
      $2\r\n37\r\n
      $8\r\nhumidity\r\n
      $2\r\n94\r\n
      ```

      The lines are separated into new lines for readability. The return value is just one line.

      `XREAD` supports other optional arguments, but we won't deal with them right now.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      First, an entry will be added.

      ```bash
      $ redis-cli XADD stream_key 0-1 temperature 96
      ```

      It'll then send an `XREAD` command to your server.

      ```bash
      $ redis-cli XREAD streams stream_key 0-0
      ```

      Your server should respond with the following:

      ```text
      *1\r\n
      *2\r\n
      $9\r\nstream_key\r\n
      *1\r\n
      *2\r\n
      $3\r\n0-1\r\n
      *2\r\n
      $11\r\ntemperature\r\n
      $2\r\n96\r\n
      ```

      This is the RESP encoded representation of the following.

      ```json
      [
        [
          "stream_key",
          [
            [
              "0-1",
              [
                "temperature",
                "96"
              ]
            ]
          ]
        ]
      ]
      ```

      ### Notes
      - In the response, the items are separated onto new lines for readability. The tester expects all of these to be in one line.
    marketing_md: |
      In this stage, you'll add support to querying a stream using the `XREAD` command.

  - slug: "streams-xread-multiple"
    primary_extension_slug: "streams"
    name: "Query multiple streams using XREAD"
    difficulty: medium
    description_md: |
      In this stage, you'll add extend support to `XREAD` to allow querying multiple streams.

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      First, an entry will be added to a couple of streams.

      ```bash
      $ redis-cli XADD stream_key 0-1 temperature 95
      $ redis-cli XADD other_stream_key 0-2 humidity 97
      ```

      It'll then send an `XREAD` command to your server with multiple streams.

      ```bash
      $ redis-cli XREAD streams stream_key other_stream_key 0-0 0-1
      ```

      Your server should respond with the following:

      ```text
      *2\r\n
      *2\r\n
      $9\r\nstream_key\r\n
      *1\r\n
      *2\r\n
      $3\r\n0-1\r\n
      *2\r\n
      $11\r\ntemperature\r\n
      $2\r\n95\r\n
      *2\r\n
      $14\r\nother_stream_key\r\n
      *1\r\n
      *2\r\n
      $3\r\n0-2\r\n
      *2\r\n
      $8\r\nhumidity\r\n
      $2\r\n97\r\n
      ```

      This is the RESP encoded representation of the following.

      ```json
      [
        [
          "stream_key",
          [
            [
              "0-1",
              [
                "foo",
                "bar"
              ]
            ]
          ]
        ],
        [
          "other_stream_key",
          [
            [
              "0-2",
              [
                "bar",
                "baz"
              ]
            ]
          ]
        ]
      ]
      ```

      ### Notes
      - In the response, the items are separated onto new lines for readability. The tester expects all of these to be in one line.
    marketing_md: |
      In this stage, you'll add extend support to `XREAD` to allow querying multiple streams.

  - slug: "streams-xread-block"
    primary_extension_slug: "streams"
    name: "Blocking reads"
    difficulty: hard
    description_md: |
      In this stage, you'll extend support to `XREAD` to allow for turning it into a blocking command.

      ### Understanding blocking

      `BLOCK` is one of the optional parameters that could be passed in to the `XREAD` command.

      Without blocking, the current implementation of our command is synchronous. This means that the command can get new data as long as there are items available.

      If we want to wait for new data coming in, we need blocking.

      Here's how it works.

      Let's use the entries previously shown as an example.

      ```yaml
      entries:
        - id: 1526985054069-0 # (ID of the first entry)
          temperature: 36 # (A key value pair in the first entry)
          humidity: 95 # (Another key value pair in the first entry)

        - id: 1526985054079-0 # (ID of the second entry)
          temperature: 37 # (A key value pair in the first entry)
          humidity: 94 # (Another key value pair in the first entry)

        # ... (and so on)
      ```

      On one instance of the redis-cli, we'd add an entry and send  a blocking `XREAD` command.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 1000 streams some_key 1526985054069-0
      ```

      Then, on another instance of the redis-cli, we add another entry.

      ```bash
      $ other-redis-cli XADD some_key 1526985054079-0 temperature 37 humidity 94
      "1526985054079-0"
      ```

      If the command was sent within 1000 milliseconds, the redis-cli will respond with the added entry.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 1000 streams some_key 1526985054069-0
      1) 1) "some_key"
         2) 1) 1) 1526985054079-0
               2) 1) temperature
                  2) 37
                  3) humidity
                  4) 94
      ```

      If not, the response would be a null representation of a bulk string.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 1000 streams some_key 1526985054069-0
      (nil)
      ```

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      First, an entry will be added to a stream.

      ```bash
      $ redis-cli XADD stream_key 0-1 temperature 96
      ```

      It'll then send an `XREAD` command to your server with the `BLOCK` command.

      ```bash
      $ redis-cli XREAD block 1000 streams stream_key 0-1
      ```

      On another instance of the redis-cli, another entry will be added in 500 milliseconds after sending the `XREAD` command.

      ```bash
      $ redis-cli XADD stream_key 0-2 temperature 95
      ```

      Your server should respond with the following:

      ```text
      *1\r\n
      *2\r\n
      $9\r\stream_key\r\n
      *1\r\n
      *2\r\n
      $3\r\n0-2\r\n
      *2\r\n
      $3\r\ntemperature\r\n
      $3\r\n96\r\n
      ```

      This is the RESP encoded representation of the following.

      ```json
      [
        [
          "stream_key",
          [
            "0-2",
            [
              "temperature",
              "96"
            ]
          ]
        ]
      ]
      ```

      It'll send another `XREAD` command to your server with the `BLOCK` command but this time, it'll wait for 2000 milliseconds before checking the response of your server.

      ```bash
      $ redis-cli XREAD block 1000 streams stream_key 0-2
      ```

      Your server should respond with `$-1\r\n` which is a `null` representation of a RESP bulk string.

      ### Notes
      - In the response, the items are separated onto new lines for readability. The tester expects all of these to be in one line.
    marketing_md: |
      In this stage, you'll add extend support to `XREAD` to allow querying multiple streams.

  - slug: "streams-xread-block-no-timeout"
    primary_extension_slug: "streams"
    name: "Blocking reads without timeout"
    difficulty: medium
    description_md: |
      In this stage, you'll extend support to `XREAD` to allow for the blocking command not timing out.

      ### Understanding blocking without timeout

      Here's how it works.

      Let's use the entries previously shown as an example.

      ```yaml
      entries:
        - id: 1526985054069-0 # (ID of the first entry)
          temperature: 36 # (A key value pair in the first entry)
          humidity: 95 # (Another key value pair in the first entry)

        - id: 1526985054079-0 # (ID of the second entry)
          temperature: 37 # (A key value pair in the first entry)
          humidity: 94 # (Another key value pair in the first entry)

        # ... (and so on)
      ```

      On one instance of the redis-cli, we'd add an entry and send a blocking `XREAD` command with 0 as the time passed in.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 0 streams some_key 1526985054069-0
      ```

      Then, on another instance of the redis-cli, we add another entry.

      ```bash
      $ other-redis-cli XADD some_key 1526985054079-0 temperature 37 humidity 94
      "1526985054079-0"
      ```

      The difference now is that the first instance of the redis-cli doesn't time out and responds with null no matter how much time passes. It will wait until another entry is added. The return value after an entry is added is similar to the last stage.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 0 streams some_key 1526985054069-0
      1) 1) "some_key"
         2) 1) 1) 1526985054079-0
               2) 1) temperature
                  2) 37
                  3) humidity
                  4) 94
      ```

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      First, an entry will be added to a stream.

      ```bash
      $ redis-cli XADD stream_key 0-1 temperature 96
      ```

      It'll then send an `XREAD` command to your server with the `BLOCK` command with the time passed in being 0.

      ```bash
      $ redis-cli XREAD block 0 streams stream_key 0-0
      ```

      It'll then wait for 1000 milliseconds before checking if there is a response. Your server should not have a new response. It'll then add another entry.

      ```bash
      $ redis-cli XADD stream_key 0-2 temperature 95
      ```

      Your server should respond with the following:

      ```text
      *1\r\n
      *2\r\n
      $9\r\stream_key\r\n
      *1\r\n
      *2\r\n
      $3\r\n0-2\r\n
      *2\r\n
      $3\r\ntemperature\r\n
      $3\r\n95\r\n
      ```

      This is the RESP encoded representation of the following.

      ```json
      [
        [
          "stream_key",
          [
            "0-2",
            [
              "temperature",
              "95"
            ]
          ]
        ]
      ]
      ```

      ### Notes
      - In the response, the items are separated onto new lines for readability. The tester expects all of these to be in one line.
    marketing_md: |
      In this stage, you'll add extend support to `XREAD` to allow for the blocking command not timing out.

  - slug: "streams-xread-block-max-id"
    primary_extension_slug: "streams"
    name: "Blocking reads using $"
    difficulty: easy
    description_md: |
      In this stage, you'll extend support to `XREAD` to allow for passing in `$` as the ID for a blocking command.

      ### Understanding $

      Using `$` as the ID passed to a blocking `XREAD` command signals that we only want new entries. This is similar to passing in the maximum ID we currently have in the stream.

      Here's how it works.

      Let's use the entries previously shown as an example.

      ```yaml
      entries:
        - id: 1526985054069-0 # (ID of the first entry)
          temperature: 36 # (A key value pair in the first entry)
          humidity: 95 # (Another key value pair in the first entry)

        - id: 1526985054079-0 # (ID of the second entry)
          temperature: 37 # (A key value pair in the first entry)
          humidity: 94 # (Another key value pair in the first entry)

        # ... (and so on)
      ```

      On one instance of the redis-cli, we'd add an entry and send a blocking `XREAD` command with `1000` as the time passed in and `$` as the id passed in.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 1000 streams some_key $
      ```

      Then, on another instance of the redis-cli, we add another entry.

      ```bash
      $ other-redis-cli XADD some_key 1526985054079-0 temperature 37 humidity 94
      "1526985054079-0"
      ```

      Similar to the behavior detailed in the earlier stages, if the command was sent within 1000 milliseconds, the redis-cli will respond with the new entry.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 1000 streams some_key 1526985054069-0
      1) 1) "some_key"
         2) 1) 1) 1526985054079-0
               2) 1) temperature
                  2) 37
                  3) humidity
                  4) 94
      ```

      If not, the return type would still be a null representation of a bulk string.

      ```bash
      $ redis-cli XADD some_key 1526985054069-0 temperature 36 humidity 95
      "1526985054069-0"
      $ redis-cli XREAD block 1000 streams some_key 1526985054069-0
      (nil)
      ```

      ### Tests

      The tester will execute your program like this:

      ```bash
      $ ./spawn_redis_server.sh
      ```

      First, an entry will be added to a stream.

      ```bash
      $ redis-cli XADD stream_key 0-1 temperature 96
      ```

      It'll then send an `XREAD` command to your server with the `BLOCK` command with `0` as the time and `$` as the ID.

      ```bash
      $ redis-cli XREAD block 0 streams stream_key $
      ```

      On another instance of the redis-cli, another entry will be added in 500 milliseconds after sending the `XREAD` command.

      ```bash
      $ redis-cli XADD stream_key 0-2 temperature 95
      ```

      Your server should respond with the following:

      ```text
      *1\r\n
      *2\r\n
      $9\r\stream_key\r\n
      *1\r\n
      *2\r\n
      $3\r\n0-2\r\n
      *2\r\n
      $3\r\ntemperature\r\n
      $3\r\n96\r\n
      ```

      This is the RESP encoded representation of the following.

      ```json
      [
        [
          "stream_key",
          [
            "0-2",
            [
              "temperature",
              "95"
            ]
          ]
        ]
      ]
      ```

      It'll send another `XREAD` command to your server with the `BLOCK` command but this time, it'll wait for 2000 milliseconds before checking the response of your server.

      ```bash
      $ redis-cli XREAD block 1000 streams stream_key $
      ```

      Your server should respond with `$-1\r\n` which is a `null` representation of a RESP bulk string.

      ### Notes
      - In the response, the items are separated onto new lines for readability. The tester expects all of these to be in one line.
    marketing_md: |
      In this stage, you'll add extend support to `XREAD` to allow for passing in `$` as the ID for a blocking command.