diff --git a/CLAUDE.md b/CLAUDE.md
index 70d4baa60..5877ed343 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -115,7 +115,9 @@ pnpm build
 pnpm preview
 ```
 
-Docs content lives in `docs/src/content/docs/` as `.md` and `.mdx` files organized by topic: `domain/`, `persistence/`, `application/`, `subscriptions/`, `read-models/`, `producers/`, `gateway/`, `diagnostics/`, and `infra/` (per-provider: esdb, postgres, mongodb, mssql, sqlite, kafka, rabbitmq, pubsub, elastic). MDX files can use Astro components. Mermaid diagrams are supported via `starlight-client-mermaid` plugin. Versioned docs (0.15) are managed by the `starlight-versions` plugin in `docs/src/content/docs/0.15/`. Sidebar is configured in `astro.config.mjs`. Frontmatter uses Starlight format (`sidebar.order` for ordering, not `sidebar_position`).
+Docs content lives in `docs/src/content/docs/` as `.md` and `.mdx` files organized by topic: `domain/`, `persistence/`, `application/`, `subscriptions/`, `read-models/`, `producers/`, `gateway/`, `diagnostics/`, and `infra/` (per-provider: esdb, postgres, mongodb, mssql, sqlite, kafka, rabbitmq, pubsub, azure-service-bus, elastic). MDX files can use Astro components. Mermaid diagrams are supported via `starlight-client-mermaid` plugin. Sidebar is auto-generated from directories in `astro.config.mjs`. Frontmatter uses Starlight format (`sidebar.order` for ordering, not `sidebar_position`).
+
+For detailed docs versioning and authoring rules, see `docs/DOCS_VERSIONING.md`.
 
 ## Code Style
 
diff --git a/docs/DOCS_VERSIONING.md b/docs/DOCS_VERSIONING.md
new file mode 100644
index 000000000..9259ac461
--- /dev/null
+++ b/docs/DOCS_VERSIONING.md
@@ -0,0 +1,82 @@
+# Docs Versioning & Authoring Guide
+
+This file is for Claude Code. It documents how the Eventuous docs site versioning works so docs can be updated correctly.
+
+## Version Structure
+
+Managed by the `starlight-versions` plugin in `astro.config.mjs`.
+
+```
+docs/src/content/docs/          ← "current" version (root, shown by default)
+docs/src/content/docs/0.15/     ← archived v0.15 snapshot
+docs/src/content/docs/next/     ← preview placeholder for future version
+docs/src/content/versions/      ← sidebar configs per version (JSON)
+```
+
+- **Root** (`docs/src/content/docs/`) is always the current stable version.
+- **Archived versions** (e.g. `0.15/`) are read-only snapshots. Don't edit unless fixing a bug in old docs.
+- **`next/`** is a minimal placeholder. When preparing a new release, content accumulates here, then gets promoted to root.
+
+## Config in astro.config.mjs
+
+```js
+starlightVersions({
+  current: { label: 'v0.16 (Stable)' },
+  versions: [
+    { slug: '0.15', label: 'v0.15' },
+    { slug: 'next', label: 'Preview' },
+  ],
+}),
+```
+
+Each entry in `versions` must have a matching directory under `docs/src/content/docs/{slug}/` and a sidebar config at `docs/src/content/versions/{slug}.json`.
+
+## Relative Path Rules
+
+Component imports and markdown links use different base paths. Getting these wrong breaks the build.
+
+### Component imports (filesystem-relative)
+
+From `docs/src/content/docs/` to `docs/src/components/`:
+
+| File location | Import path |
+|---|---|
+| Root subdirectory (e.g. `subscriptions/checkpoint.mdx`) | `../../../components/Foo.astro` (3 levels) |
+| Versioned subdirectory (e.g. `0.15/subscriptions/checkpoint.mdx`) | `../../../../components/Foo.astro` (4 levels) |
+
+### Markdown links (doc-tree-relative)
+
+Internal doc links resolve within the doc tree, not the filesystem:
+
+| File location | Link to another section |
+|---|---|
+| Root subdirectory (e.g. `infra/esdb.md`) | `../../application/app-service` (2 levels) |
+| `next/` subdirectory (e.g. `next/infra/esdb.md`) | `../../../application/app-service` (3 levels) |
+
+### Hero image (index.mdx)
+
+| File location | Image path to `src/assets/logo.png` |
+|---|---|
+| Root `index.mdx` | `../../assets/logo.png` |
+| `0.15/index.mdx` | `../../../assets/logo.png` |
+
+## How to Release a New Version
+
+To promote `next/` to a new stable version (e.g. v0.17):
+
+1. **Archive current root** → copy root content (excluding `next/` and version dirs) into a new directory (e.g. `0.16/`). Create a matching `src/content/versions/0.16.json` sidebar config (copy from `next.json` template).
+2. **Replace root with `next/`** → delete root content files, copy `next/` to root.
+3. **Fix relative paths** → reduce all `../` depths by 1 in the new root files (component imports: 4→3, markdown links: 3→2, hero image: 3→2).
+4. **Fix archived version paths** → increase all `../` depths by 1 in the archived directory (component imports: 3→4).
+5. **Update `astro.config.mjs`** → change `current.label`, add archived version to `versions` array.
+6. **Reset `next/`** → delete all content, create a single `whats-new.mdx` placeholder. Update `next.json` sidebar to only reference `whats-new`.
+7. **Build and verify** → `pnpm build` must pass. Check page count and spot-check version selector.
+
+> **Do not** rely on the plugin's auto-snapshot feature (`ensureNewVersion`). It fails on MDX files with complex Astro expressions. Always snapshot manually.
+
+## Adding New Doc Pages
+
+- Add `.md` or `.mdx` files to the appropriate topic directory under root docs.
+- The sidebar auto-generates from directory contents. Use `sidebar.order` in frontmatter to control ordering.
+- For new infrastructure providers, add to `infra/` with a descriptive filename (e.g. `azure-service-bus.md`).
+- If adding pages to `next/` for a future version, remember that all relative paths need one extra `../` compared to root.
diff --git a/docs/astro.config.mjs b/docs/astro.config.mjs
index 3ff708870..b249b2fb6 100644
--- a/docs/astro.config.mjs
+++ b/docs/astro.config.mjs
@@ -18,8 +18,11 @@ export default defineConfig({
       customCss: ['./src/styles/custom.css'],
       plugins: [
         starlightVersions({
-          current: { label: 'v0.15 (Stable)' },
-          versions: [{ slug: 'next', label: 'Preview' }],
+          current: { label: 'v0.16 (Stable)' },
+          versions: [
+            { slug: '0.15', label: 'v0.15' },
+            { slug: 'next', label: 'Preview' },
+          ],
         }),
         starlightMermaid(),
       ],
diff --git a/docs/src/components/ThemedImage.astro b/docs/src/components/ThemedImage.astro
index 74244d241..a36c7c7d3 100644
--- a/docs/src/components/ThemedImage.astro
+++ b/docs/src/components/ThemedImage.astro
@@ -1,16 +1,19 @@
 ---
+import { Image } from 'astro:assets';
+import type { ImageMetadata } from 'astro';
+
 interface Props {
   alt: string;
-  lightSrc: string;
-  darkSrc: string;
+  lightSrc: ImageMetadata;
+  darkSrc: ImageMetadata;
 }
 
 const { alt, lightSrc, darkSrc } = Astro.props;
 ---
 
 <picture class="themed-image">
-  <img class="light-only" src={lightSrc} alt={alt} />
-  <img class="dark-only" src={darkSrc} alt={alt} />
+  <Image class="light-only" src={lightSrc} alt={alt} />
+  <Image class="dark-only" src={darkSrc} alt={alt} />
 </picture>
 
 <style>
diff --git a/docs/src/content/docs/application/app-service.mdx b/docs/src/content/docs/0.15/application/app-service.mdx
similarity index 99%
rename from docs/src/content/docs/application/app-service.mdx
rename to docs/src/content/docs/0.15/application/app-service.mdx
index a894a74ef..719af0798 100644
--- a/docs/src/content/docs/application/app-service.mdx
+++ b/docs/src/content/docs/0.15/application/app-service.mdx
@@ -2,7 +2,7 @@
 title: "Service with aggregate"
 description: "Command service and unit of work for aggregates"
 sidebar:
-  order: 1
+  order: 10
 ---
 
 ## Concept
@@ -163,4 +163,4 @@ You can simplify your application and avoid creating HTTP endpoints explicitly (
 
 The most common use case is to connect the command service to an HTTP API using controllers or minimal API mappings.
 
-Read the [Command API](../command-api) feature documentation for more details.
\ No newline at end of file
+Read the [Command API](../command-api) feature documentation for more details.
diff --git a/docs/src/content/docs/0.15/application/command-api.md b/docs/src/content/docs/0.15/application/command-api.md
new file mode 100644
index 000000000..fe5b59569
--- /dev/null
+++ b/docs/src/content/docs/0.15/application/command-api.md
@@ -0,0 +1,354 @@
+---
+title: "Using services in HTTP API"
+description: "Auto-generated HTTP API for command handling"
+sidebar:
+  order: 30
+---
+
+:::note
+Install `Eventuous.Extensions.AspNetCore` package for using Eventuous HTTP API support.
+:::
+
+## Controller base
+
+Eventuous allows you to simplify the command handling in the API controller by using a `CommandHttpApiBase<TState>` abstract class, which implements
+the `ControllerBase` and contains the `Handle` method. The class takes `ICommandService<TState>` as a dependency. The `Handle` method will call the command
+service, and also convert the handling result to `ActionResult<Result<TState>.Ok>`. Here are the rules for exception handling:
+
+| Result exception                 | HTTP response |
+|----------------------------------|---------------|
+| `OptimisticConcurrencyException` | `Conflict`    |
+| `AggregateNotFoundException`     | `NotFound`    |
+| Any other exception              | `BadRequest`  |
+
+Here is an example of a command API controller:
+
+```csharp
+[Route("/booking")]
+public class CommandApi(ICommandService<BookingState> service) 
+    : CommandHttpApiBase<BookingState> {
+    [HttpPost]
+    [Route("book")]
+    public Task<ActionResult<Result<BookingState>.Ok>> BookRoom(
+        [FromBody] BookRoom cmd, 
+        CancellationToken cancellationToken
+    ) => Handle(cmd, cancellationToken);
+}
+```
+
+Although the controller endpoint method returns `ActionResult<Result<TState>.Ok>`, it does that only if the command was handled successfully. If the command
+service was unable to process the command, it will generate an instance of:
+
+* `ProblemDetails` with status code `404` if there's no stream to operate on
+* `ProblemDetails` with status code `409` in case of optimistic concurrency issues
+* `ValidationProblemDetails` with `400` status code in case there was a domain exception
+* `ProblemDetails` with status code `500` for any other issue
+
+For making those responses available in the OpenAPI generated documentation, you'd need to annotate your controller methods accordingly. Eventuous provides
+several attributes to help with that, as well as an attribute to specify the success return type if your controller endpoint returns `IActionResult`:
+
+```csharp
+public class BookingApi(ICommandService<BookingState> service)
+    : CommandHttpApiBase<BookingState>(service) {
+    [HttpPost("v2/pay")]
+    [ProducesResult<BookingState>]
+    [ProducesConflict]
+    [ProducesDomainError]
+    [ProducesNotFound]
+    public async Task<IActionResult?> RegisterPayment(
+        [FromBody] RegisterPaymentHttp cmd, 
+        CancellationToken cancellationToken
+    ) {
+        var result = await Handle(cmd, cancellationToken);
+
+        return result.Result;
+    }
+}
+```
+
+## Generated command API
+
+Eventuous can use your command service to generate a command API. Such an API will accept JSON models matching the application service command contracts, and
+pass those commands as-is to the application service. This feature removes the need to create API endpoints manually using controllers or .NET minimal API.
+
+All the auto-generated API endpoints will use the `POST` HTTP method.
+
+### Annotating commands
+
+For Eventuous to understand what commands need to be exposed as API endpoints and on what routes, those commands need to be annotated by the `HttpCommand`
+attribute:
+
+```csharp
+[HttpCommand<BookingState>(Route = "payment")]
+public record ProcessPayment(string BookingId, float PaidAmount);
+```
+
+Eventuous will then map the command to an HTTP `POST` endpoint that will resolve an instance of `ICommandService<BookingState>` which can be either a
+aggregate-based command service or a functional service, and pass the command to it.
+
+You can skip the `Route` property, in that case Eventuous will use the command class name. For the example above the generated route would be `processPayment`.
+We recommend specifying the route explicitly as you might refactor the command class and give it a different name, and it will break your API if the route is
+auto-generated.
+
+If your application has a single command service working with a single state type, you don't need to specify the state type, and then use a different command
+registration method (described below).
+
+Another way to specify the state type for a group of commands is to annotate the parent class (command container):
+
+```csharp
+[StateCommands<BookingState>()]
+public static class BookingCommands {
+    [HttpCommand(Route = "payment")]
+    public record ProcessPayment(string BookingId, float PaidAmount);
+}
+```
+
+In such case, Eventuous will treat all the commands defined inside the `BookingCommands` static class as commands operating on `BookingState`.
+
+Also, you don't need to specify the state type in the command annotation if you use the `MapCommands` registration (see below).
+
+Finally, you don't need to annotate the command at all if you use the explicit command registration with the route parameter.
+
+### Registering commands
+
+There are several extensions for `IEndpointRouteBuilder` that allow you to register HTTP endpoints for one or more commands.
+
+#### Single command
+
+The simplest way to register a single command is to make it explicitly in the bootstrap code:
+
+```csharp
+var builder = WebApplication.CreateBuilder();
+
+// Register the app service
+builder.Services.AddCommandService<BookingService, BookingState>();
+
+var app = builder.Build();
+
+// Map the command to an API endpoint
+app.MapCommand<ProcessPayment, BookingState>("payment");
+
+app.Run();
+
+record ProcessPayment(string BookingId, float PaidAmount);
+```
+
+If you annotate the command with the `HttpCommand` attribute, and specify the route, you can avoid providing the route when registering the command:
+
+```csharp
+app.MapCommand<ProcessPayment, BookingState>();
+
+...
+
+[HttpCommand(Route = "payment")]
+public record ProcessPayment(string BookingId, float PaidAmount);
+```
+
+#### Multiple commands for one service
+
+You can also register multiple commands for the same service type without a need to provide the state type in the command annotation. To do that, use the
+extension that will create an `CommandServiceRouteBuilder`, then register commands using that builder:
+
+```csharp
+app
+    .MapCommands<BookingState>()
+    .MapCommand<ProcessPayment>()
+    .MapCommand<ApplyDiscount>("discount");
+
+...
+
+// route specified in the annotation
+[HttpCommand(Route = "payment")] 
+public record ProcessPayment(string BookingId, float PaidAmount);
+
+// No annotation needed
+public record ApplyDiscount(string BookingId, float Discount);
+```
+
+#### Discover commands
+
+There are two extensions that are able to scan your application for annotated commands, and register them automatically.
+
+First, the `MapDiscoveredCommand<TState>`, which assumes your application only serves commands with a single service type:
+
+```csharp
+app.MapDiscoveredCommands<BookingState>();
+
+...
+
+[HttpCommand(Route = "payment")] 
+record ProcessPayment(string BookingId, float PaidAmount);
+```
+
+For it to work, all the commands must be annotated and have the route defined in the annotation.
+
+The second extension will discover all the annotated commands, which need to have an association with the command service type by using the `StateType` argument
+of the attribute, or by using the `HttpCommands` attribute on the container class (described above):
+
+```csharp
+app.MapDiscoveredCommands();
+
+...
+
+[HttpCommand<BookingState>(Route = "bookings/payment")] 
+record ProcessPayment(string BookingId, float PaidAmount);
+
+[HttpCommands<PaymentState>]
+class V1.PaymentCommands {
+    [HttpCommand(Route = "payments/register")]
+    public record RegisterPayment(string PaymentId, string Provider, float Amount);
+
+    [HttpCommand(Route = "payments/refund")]
+    public record RefundPayment(string PaymentId);
+}
+```
+
+Both extensions will scan the current assembly by default, but you can also provide a list of assemblies to scan as an argument:
+
+```csharp
+app.MapDiscoveredCommands(typeof(V1.PaymentCommands).Assembly);
+```
+
+## Command separation and enrichment
+
+Eventuous supports converting external (public) commands to internal (private) commands, as well as enriching commands with data that isn't coming directly via
+the message (as, HTTP or gRPC message) but is available in the transport context (`HttpContext` as an example).
+
+Here are some example cases for this:
+
+* Convert external HTTP commands to internal domain commands. It allows using value objects for internal commands and support early validation of the values
+  provided in the HTTP call, and avoid unnecessary reads from the database if the request is invalid.
+* Convert commands in multiple API versions to the same domain commands.
+* Populating command properties with values available in the transport context, like `HttpContext.User`.
+
+### For controllers
+
+When using the `CommandHttpApiBase` for controllers, you can provide an optional command map that instructs the controller how the HTTP API contract can be
+enriched with `HttpContext` data or converted to a different command type. You'd need to add all command transformations and enrichments to the command map, so
+it can be used across all the controllers.
+
+When you want to separate internal and external commands, commands could be defined like this:
+
+```csharp 
+// HTTP contract
+public record RegisterPaymentHttp(
+    string         BookingId,
+    string         PaymentId,
+    float          Amount,
+    DateTimeOffset PaidAt
+);
+
+// Domain command using value objects
+public record RecordPayment(
+    BookingId      BookingId,
+    string         PaymentId,
+    Money          Amount,
+    DateTimeOffset PaidAt,
+    string         PaidBy // Additional information fro HttpContext
+);
+```
+
+For example, the code below creates an instance of a command map and adds one transformation to it:
+
+```csharp
+var commandMap = new CommandMap<HttpContext>()
+    .Add<RegisterPaymentHttp, RecordPayment>((x, ctx) => 
+        new(
+            new BookingId(x.BookingId), 
+            x.PaymentId, 
+            new Money(x.Amount), 
+            x.PaidAt, 
+            ctx.User.Identity?.Name
+        )
+    );
+```
+
+Of course, if you don't want to separate external and internal commands, you can use the same but simplified technique. In that case, you'd want to hide the
+additional property using the `JsonIgnore` attribute, so it doesn't show up in the OpenAPI spec.
+
+```csharp
+public record RegisterPayment(BookingId Id, string PaymentId, Money Amount, LocalDate PaidAt) {
+    [JsonIgnore] 
+    string? PaidBy {get; init; }
+}
+
+var commandMap = new CommandMap<HttpContext>()
+    .Add<RecordPayment>((x, ctx) => x with { PaidBy = ctx.User.Identity?.Name });
+```
+
+For using the command map in controllers, you'd need to register it in the DI container as a singleton:
+
+```csharp title="Program.cs"
+builder.Services.AddSingleton(commandMap);
+```
+
+### For generated routes
+
+It's possible to assign command properties from `HttpContext` when using extended versions of the `MapCommand` function. This method doesn't work with
+discovered commands.
+
+First, you'd want to hide properties that are populated from `HttpContext` so they don't show up in the OpenAPI spec. To hide a property from being exposed to
+the client, use the `JsonIgnore` attribute:
+
+```csharp
+[HttpCommand(Route = "book")]
+public record BookRoom(string RoomId, string BookingId, [property: JsonIgnore] string UserId);
+```
+
+Then, you can use the `HttpContext` data in your command:
+
+```csharp title="Program.cs"
+var app = builder.Build();
+
+app
+    .MapCommands<BookingState>()
+    .MapCommand<BookRoom>((cmd, ctx) => cmd with { UserId = ctx.User.Identity.Name });
+```
+
+When the command is mapped to the API endpoint like that, and the property is ignored, the OpenAPI specification won't include the ignored property, and the
+command service will get the command populated with the user id from `HttpContext`.
+
+Uou can also use the `Map` method to map the contract to the domain command. You can also use data from the `HttpContext` to add additional information to the
+command, like the user identity. There's no need to add ignored properties to the contract in this case.
+
+Consider the contract record being decorated by the `HttpCommand` attribute:
+
+```csharp title="HTTP contract"
+[HttpCommand(Route = "pay")]
+public record RegisterPaymentHttp(
+    string         BookingId,
+    string         PaymentId,
+    float          Amount,
+    DateTimeOffset PaidAt
+);
+```
+
+We can then define the domain command with an additional `PaidBy` property:
+
+```csharp title="Domain command"
+public record RecordPayment(
+    BookingId      BookingId,
+    string         PaymentId,
+    Money          Amount,
+    DateTimeOffset PaidAt,
+    string         PaidBy // Additional information fro HttpContext
+);
+```
+
+Then, use a more advanced overload of `MapCommand` to apply transformation and enrichment:
+
+```csharp title="Program.cs"
+var app = builder.Build();
+
+app
+    .MapCommands<BookingState>()
+    .MapCommand<ProcessPaymentHttp, Commands.ProcessPayment>(
+        (cmd, ctx) => new Commands.ProcessPayment(
+            new BookingId(cmd.BookingId), // Create value object from primitive
+            cmd.PaymentId,                // Use primitive
+            new Money(cmd.Amount),
+            cmd.PaidAt,
+            ctx.User.Identity.Name        // Use HttpContext to get user details
+        )
+    );
+```
diff --git a/docs/src/content/docs/application/func-service.mdx b/docs/src/content/docs/0.15/application/func-service.mdx
similarity index 99%
rename from docs/src/content/docs/application/func-service.mdx
rename to docs/src/content/docs/0.15/application/func-service.mdx
index ae15086f2..9ebd29dcf 100644
--- a/docs/src/content/docs/application/func-service.mdx
+++ b/docs/src/content/docs/0.15/application/func-service.mdx
@@ -2,7 +2,7 @@
 title: "Service with state"
 description: "Functional command service and unit of work without aggregates"
 sidebar:
-  order: 3
+  order: 20
 ---
 
 ## Concept
@@ -164,4 +164,4 @@ You can simplify your application and avoid creating HTTP endpoints explicitly (
 
 The most common use case is to connect the command service to an HTTP API using controllers or minimal API mappings.
 
-Read the [Command API](../command-api) feature documentation for more details.
\ No newline at end of file
+Read the [Command API](../command-api) feature documentation for more details.
diff --git a/docs/src/content/docs/0.15/application/index.mdx b/docs/src/content/docs/0.15/application/index.mdx
new file mode 100644
index 000000000..9a92e73fc
--- /dev/null
+++ b/docs/src/content/docs/0.15/application/index.mdx
@@ -0,0 +1,19 @@
+---
+title: "Application"
+description: "Application layer and service"
+sidebar:
+  order: 1
+---
+
+The application layer sits between the system edge (different APIs), and the domain model. It is responsible for handling commands coming from the edge.
+
+## Concept
+
+In general, the command handling flow can be described like this:
+
+1. The edge receives a command via its API (HTTP, gRPC, SignalR, messaging, etc).
+2. It passes the command over to the command service. As the edge is responsible for authentication and some authorization, it can enrich commands with user credentials.
+3. The command service, which is agnostic to the API itself, handles the command and gives a response to the edge (positive or negative).
+4. The API layer then returns the response to the calling party.
+
+Eventuous provides several ways to implement the application layer, described in this section.
diff --git a/docs/src/content/docs/diagnostics/index.mdx b/docs/src/content/docs/0.15/diagnostics/index.mdx
similarity index 100%
rename from docs/src/content/docs/diagnostics/index.mdx
rename to docs/src/content/docs/0.15/diagnostics/index.mdx
diff --git a/docs/src/content/docs/diagnostics/logs.md b/docs/src/content/docs/0.15/diagnostics/logs.md
similarity index 100%
rename from docs/src/content/docs/diagnostics/logs.md
rename to docs/src/content/docs/0.15/diagnostics/logs.md
diff --git a/docs/src/content/docs/diagnostics/metrics.md b/docs/src/content/docs/0.15/diagnostics/metrics.md
similarity index 100%
rename from docs/src/content/docs/diagnostics/metrics.md
rename to docs/src/content/docs/0.15/diagnostics/metrics.md
diff --git a/docs/src/content/docs/diagnostics/opentelemetry.md b/docs/src/content/docs/0.15/diagnostics/opentelemetry.md
similarity index 100%
rename from docs/src/content/docs/diagnostics/opentelemetry.md
rename to docs/src/content/docs/0.15/diagnostics/opentelemetry.md
diff --git a/docs/src/content/docs/diagnostics/traces.md b/docs/src/content/docs/0.15/diagnostics/traces.md
similarity index 100%
rename from docs/src/content/docs/diagnostics/traces.md
rename to docs/src/content/docs/0.15/diagnostics/traces.md
diff --git a/docs/src/content/docs/0.15/domain/aggregate.md b/docs/src/content/docs/0.15/domain/aggregate.md
new file mode 100644
index 000000000..cc7c83ca1
--- /dev/null
+++ b/docs/src/content/docs/0.15/domain/aggregate.md
@@ -0,0 +1,199 @@
+---
+title: "Aggregate"
+description: "Aggregate: consistency boundaries"
+sidebar:
+  order: 1
+---
+
+:::info
+From version **0.14.0** using aggregates is **optional**. You can define your domain logic using [functional services](../../application/func-service) instead.
+:::
+
+:::info
+From version **0.15.0**, non-generic `Aggregate` abstraction is gone, so you have to use `Aggregate<TState>`.
+:::
+
+## Concept
+
+:::note
+If you are familiar with the concept, [scroll down](#implementation).
+:::
+
+`Aggregate` is probably the most important tactical pattern in Domain-Driven Design. It is a building block of the domain model. An `Aggregate` is a model on its own, a model of a particular business objects, which can be uniquely identified and by that distinguished from any other object of the same kind.
+
+When handling a command, you need to ensure it only changes the state of a single aggregate. An aggregate boundary is a transaction boundary, so the state transition for the aggregate needs to happen entirely or not at all.
+
+:::tip[No entities]
+**TD;LR** Eventuous doesn't have entities other than the Aggregate Root. If you are okay with that, [scroll down](#implementation).
+:::
+
+Traditionally, DDD defines three concepts, which are related to aggregate:
+- `Entity` - a representation of a business object, which has an identifier
+- `Aggregate Root` - an entity, which might aggregate other entities and value objects
+- `Aggregate` - the `Aggregate Root` and all the things inside it
+
+The idea of an aggregate, which holds more than one entity, seems to be derived from the technical concerns of persisting the state. You can imagine an aggregate root type called `Booking` (for a hotel room), which holds a collection of `ExtraService` entities. Each of those entities represent a single extra service ordered by the guest when they made this booking. It could be a room service late at night, a baby cot, anything else that the guest needs to order in advance. Since those extra services might be also cancelled, we need to have a way to uniquely identify each of them inside the `Booking` aggregate, so those are entities.
+
+If we decide to persist the `Booking` state in a relational database, the natural choice would be to have one table for `Booking` and one table for `ExtraService` with one-to-many relationship. Still, when loading the `Booking` state, we load the whole aggregate, so we have to read from the `Booking` table with inner join on the `ExtraService` table.
+
+Those entities might also have behaviour, but to reach out to an entity within an aggregate, you go through the aggregate root (`Booking`). For example, to cancel the baby cot service, we'd have code like this:
+
+```csharp
+var booking = bookingRepository.Load(bookingId);
+booking.CancelExtraService(extraServiceId);
+bookingRepository.Save(booking);
+```
+
+In the `Booking` code it would expand to:
+
+```csharp
+void CancelExtraService(ExtraServiceId id) {
+    extraServices.RemoveAll(x => x.Id == id);
+    RecalculateTotal();
+}
+```
+
+So, we have an entity here, but it doesn't really expose any behaviour. Even if it does, you first call the aggregate root logic, which finds the entity, and then routes the call to the entity.
+
+In Eventuous, we consider it as a burden. If you need to find the entity in the aggregate root logic, why can't you also execute the operation logic right away? If you want to keep the entity logic separated, you can always create a module with a pure function, which takes the entity state and returns an event to the aggregate root.
+
+The relational database persistence concern doesn't exist in Event Sourcing world. Therefore, we decided not to implement concepts like `Entity` and `AggregateRoot`. Instead, we provide a single abstraction for the logical and physical transaction boundary, which is the `Aggregate`.
+
+## Implementation
+
+Eventuous provides three abstract classes for the `Aggregate` pattern, which are all event-sourced. The reason to have three and not one is that all of them allow you to implement the pattern differently. You can choose the one you prefer.
+
+### Aggregate
+
+The `Aggregate` abstract class is quite technical and provides very little out of the box. Unconditionally, since version 0.15 Eventuous only supports `Aggregate<TState>` type, where `TState` is the aggregate state type. Traditionally, we consider the state as part of the aggregate. However, state is the only part of the aggregate that gets mutated. The pattern used by Eventuous is to separate state from the behaviour by splitting them into two distinct objects. 
+
+The aggregate state in Eventuous is _immutable_. When applying an event to it, we get a new state.
+
+:::tip[Event-sourced state]
+The `State` abstraction is described on the [State](../state) page.
+:::
+
+Here are the `Aggregate` class members:
+
+| Member            | Kind                 | What it's for                                                                                                                                                                                            |
+|-------------------|----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `Original`        | Read-only collection | Events that were loaded from the aggregate stream                                                                                                                                                        |
+| `Changes`         | Read-only collection | Events, which represent new state changes, get added here                                                                                                                                                |
+| `Current`         | Read-only collection | The collection of the historical and new events                                                                                                                                                          |
+| `ClearChanges`    | Method               | Clears the changes collection                                                                                                                                                                            |
+| `OriginalVersion` | Property, `int`      | Original aggregate version at which it was loaded from the store                                                                                                                                         |
+| `Version`         | Property, `int`      | Current aggregate version after new events were applied                                                                                                                                                  |
+| `AddChange`       | Method               | Adds an event to the list of changes                                                                                                                                                                     |
+| `Load`            | Method               | Given the list of previously stored events, restores the aggregate state. Normally, it's used for synchronous load, when all the stored events come from event store at once.                            |
+| `Apply`           | Method               | Given a domain event, applies it to the state. Replaces the current state with the new version. Adds the event to the list of changes. Returns a tuple with the previous and the current state versions. |
+| `State`           | Property             | Returns the current aggregate state.                                                                                                                                                                     |
+| `Current`         | Property             | Returns the collection of events loaded from the stream. If it's a new aggregate, it returns an empty list.                                                                                              |
+
+It also has two helpful methods, which aren't related to Event Sourcing:
+- `EnsureExists` - throws if `Version` is `-1`
+- `EnsureDoesntExist` - throws if `Version` is not `-1`
+
+The stateful aggregate class implements most of the abstract members of the original `Aggregate`. It exposes an API, which allows you to use the stateful aggregate base class directly.
+
+Here's an example of an aggregate:
+
+```csharp title="Booking.cs"
+public class Booking : Aggregate<BookingState> {
+    public void BookRoom(string roomId, StayPeriod period, Money price, string? guestId = null) {
+        EnsureDoesntExist();
+
+        Apply(new RoomBooked(roomId, period.CheckIn, period.CheckOut, price.Amount, guestId));
+    }
+
+    public void Import(string roomId, StayPeriod period, Money price) {
+        EnsureDoesntExist();
+
+        Apply(new BookingImported(roomId, price.Amount, period.CheckIn, period.CheckOut));
+    }
+
+    public void RecordPayment(string paymentId, Money amount, DateTimeOffset paidAt) {
+        EnsureExists();
+
+        if (HasPaymentRecord(paymentId)) return;
+
+        // The Apply function returns both previous and new state
+        var (previousState, currentState) =
+            Apply(new BookingPaymentRegistered(paymentId, amount.Amount));
+
+        // Using the previous state can be useful for some scenarios
+        if (previousState.AmountPaid != currentState.AmountPaid) {
+            var outstandingAmount = currentState.Price - currentState.AmountPaid;
+            Apply(new BookingOutstandingAmountChanged(outstandingAmount.Amount));
+
+            if (outstandingAmount.Amount < 0) 
+                Apply(new BookingOverpaid(-outstandingAmount.Amount));
+        }
+
+        // The next line only produces an event if the booking was not fully paid before
+        if (!previousState.IsFullyPaid() && currentState.IsFullyPaid()) 
+            Apply(new BookingFullyPaid(paidAt));
+    }
+
+    // This function uses the previously loaded events collection to 
+    // check if the payment was already recorded. You can do the same using the state.
+    public bool HasPaymentRecord(string paymentId)
+        => Current.OfType<BookingPaymentRegistered>().Any(x => x.PaymentId == paymentId);
+}
+```
+
+### Aggregate identity
+
+Eventuous `Aggregate` abstraction doesn't have an identity property. It is, however, possible to use identity-aware state types.
+The identity type must inherit from the `Id` abstract record, which needs a string value for its constructor:
+
+```csharp title="BookingId.cs"
+public record BookingId(string Value) : Id(Value);
+```
+
+The abstract record overrides its `ToString` to return the string value as-is. It also has an implicit conversion operator, which allows you to use a string value without explicitly instantiating the identity record. However, we still recommend instantiating the identity explicitly to benefit from type safety.
+
+The aggregate identity type is only used by the [command service](../../application/app-service) and for calculating the [stream name](../../persistence/aggregate-stream) for loading and saving events. When the command service loads an aggregate with identity, it sets the state identity to a value derived from the stream name. For example, when loading events from a stream `Order-123` for an aggregate type declared as `Order : Aggregate<OrderState<OrderId>>`, the `OrderId` value will be set to `123`. 
+
+## Aggregate factory
+
+Eventuous needs to instantiate your aggregates when it loads them from the store. New instances are also created by the `CommandService` when handling a command that operates on a new aggregate. Normally, aggregate classes don't have dependencies, so it is possible to instantiate one by calling its default constructor. However, you might need to have a dependency or two, like a domain service. We advise providing such dependencies when calling the aggregate function from the command service, as an argument. But it's still possible to instruct Eventuous how to construct aggregates that don't have a default parameterless constructor. That's the purpose of the `AggregateFactory` and `AggregateFactoryRegistry`.
+
+The `AggregateFactory` is a simple function:
+
+```csharp
+public delegate T AggregateFactory<out T, TState>() where T : Aggregate<TState>;
+```
+
+The registry allows you to add custom factory for a particular aggregate type. The registry itself is a singleton, accessible by `AggregateFactoryRegistry.Instance`. You can register your custom factory by using the `CreateAggregateUsing<T>` method of the registry:
+
+```csharp title="Program.cs"
+AggregateFactoryRegistry.CreateAggregateUsing<Booking, BookingState>(
+    () => new Booking(availabilityService)
+);
+```
+
+By default, when there's no custom factory registered in the registry for a particular aggregate type, Eventuous will create new aggregate instances by using reflections. It will only work when the aggregate class has a parameterless constructor (it's provided by the `Aggregate` base class).
+
+It's not a requirement to use the default factory registry singleton. Both `CommandService` and `AggregateStore` have an optional parameter that allows you to provide the registry as a dependency. When not provided, the default instance will be used. If you use a custom registry, you can add it to the DI container as singleton.
+
+### Dependency injection
+
+:::note
+Install the `Eventuous.Extensions.DependencyInjection` package to use the API described below.
+:::
+
+The aggregate factory can inject registered dependencies to newly created aggregate instances when constructing them. For this to work, you need to tell Eventuous that the aggregate needs to be constructed using the container. To do so, use the `AddAggregate<T, TState>` service collection extension:
+
+```csharp title="Program.cs"
+builder.Services.AddAggregate<Booking, BookingState>();
+builder.Services.AddAggregate<Payment, PaymentState>(
+    sp => new Payment(sp.GetRequiredService<PaymentProcessor>, otherService)
+);
+```
+
+When that's done, you also need to tell the host to use the registered factories:
+
+```csharp title="Program.cs"
+app.UseAggregateFactory();
+```
+
diff --git a/docs/src/content/docs/0.15/domain/domain-events.md b/docs/src/content/docs/0.15/domain/domain-events.md
new file mode 100644
index 000000000..f5e2d1fc7
--- /dev/null
+++ b/docs/src/content/docs/0.15/domain/domain-events.md
@@ -0,0 +1,64 @@
+---
+title: "Domain events"
+description: "Domain events: persisted behaviour"
+sidebar:
+  order: 3
+---
+
+## Concept
+
+If you ever read the [Blue Book](https://www.domainlanguage.com/ddd/blue-book/), you'd notice that the `Domain Event` concept is not mentioned there. Still, years after the book was published, events have become popular, and domain events in particular.
+
+Eric Evans, the author of the Blue Book, has added the definition to his [Domain-Design Reference](https://www.domainlanguage.com/ddd/reference/). Let us start with Eric's definition:
+
+> Model information about activity in the domain as a series of discrete events. Represent each event as a domain object. [...]
+> A domain event is a full-fledged part of the domain model, a representation of something that happened in the domain. Ignore irrelevant domain activity while making explicit the events that the domain experts want to track or be notified of, or which are associated with state changes in the other model objects.
+
+When talking about Event Sourcing, we focus on the last bit: "making explicit the events [...], which are associated with state changes." Event Sourcing takes this definition further, and suggests:
+
+> Persist the domain objects state as series of domain events. Each domain event represents an explicit state transition. Applying previously recorded events to a domain object allows us to recover the current state of the object itself.
+
+We can also cite an [article](https://suzdalnitski.medium.com/oop-will-make-you-suffer-846d072b4dce) from Medium (a bit controversial one):
+
+> In the past, the goto statement was widely used in programming languages, before the advent of procedures/functions. The goto statement simply allowed the program to jump to any part of the code during execution. This made it really hard for the developers to answer the question “how did I get to this point of execution?”. And yes, this has caused a large number of bugs.
+> A very similar problem is happening nowadays. Only this time the difficult question is **“how did I get to this state”** instead of “how did I get to this point of execution”.
+
+Event Sourcing effectively answers this question by giving you a history of all the state transitions for your domain objects, represented as domain events.
+
+So, what is this page about? It doesn't look like a conventional documentation page, does it? Nevertheless, let's see what domain events look like when you build a system with Eventuous.
+
+```csharp title="BookingEvents.cs"
+public static class BookingEvents {
+    public record RoomBooked(
+        string RoomId,
+        LocalDate CheckIn,
+        LocalDate CheckOut,
+        decimal Price
+    );
+
+    public record BookingPaid(
+        decimal AmountPaid,
+        bool PaidInFull
+    );
+
+    public record BookingCancelled(string Reason);
+
+    public record BookingImported(
+        string RoomId,
+        LocalDate CheckIn,
+        LocalDate CheckOut
+    );
+}
+```
+
+Eventuous do's and dont's:
+- **Do** make sure your domain events can be serialized to a commonly understood format, like JSON.
+- **Do** make domain events immutable.
+- **Do** implement equality by value for domain events.
+- **Don't** apply things like marker interfaces (or any interfaces) to domain events.
+- **Don't** use constructor logic, which can prevent domain events from deserializing.
+- **Don't** use value objects in your domain events.
+
+Some of those points look like limitations, and they are. For example, avoiding value objects inside domain events primarily caused by lack of separation between domain events and persisted (stored in an [event store](../../persistence/event-store)) events. It creates a requirement for the domain events to be fully (de)serializable, and it's not always possible when using value objects with their explicit validation rules. You also cannot use standard types like immutable arrays or lists as they cannot be deserialized.
+
+It's a technical limitation which will be addressed soon.
diff --git a/docs/src/content/docs/0.15/domain/state.md b/docs/src/content/docs/0.15/domain/state.md
new file mode 100644
index 000000000..577292d37
--- /dev/null
+++ b/docs/src/content/docs/0.15/domain/state.md
@@ -0,0 +1,113 @@
+---
+title: "State"
+description: "Event-sourced immutable state"
+sidebar:
+  order: 2
+---
+
+## Event-sourced state
+
+Eventuous has an abstraction for event-sourced state. The state can be used both as an aggregate state, or independently when using functions to handle commands and produce new events using the [functional service](../../application/func-service). Moving along, we consider event-based state transitions as part of the state handling. Therefore, the state object needs to expose an API to receive events and produce a new instance of itself (remember that the state is immutable).
+
+To support state immutability, `State` is an abstract _record_, not class. Therefore, it supports immutability out of the box and supports `with` syntax to make state transitions easier.
+
+A record, which inherits from `State` needs to implement a single function called `When`. It gets an event as an argument and returns the new state instance. There are two ways to define how events mutate the state, described below.
+
+### Using pattern matching
+
+:::tip[Use explicit handlers]
+Eventuous performs additional checks if event types, which are handled by the `When` function, are registered in the type map. If you use pattern matching, the check is impossible to perform, and the application can crash if the event is not registered in the type map. Therefore, we advise to use explicit handlers as described [below](#using-explicit-handlers).
+:::
+
+Using pattern matching, you can define how events mutate the state with functions that return the new `State` instance.
+
+For example:
+
+```csharp title="BookingState.cs"
+public record BookingState : State<BookingState> {
+    decimal Price { get; init; }
+
+    public override BookingState When(object @event)
+        => @event switch {
+            RoomBooked booked        => this with { Price = booked.Price },
+            BookingImported imported => this with { Price = booked.Price },
+            _                        => this
+        };
+}
+```
+
+The default branch of the switch expression returns the current instance as it received an unknown event. You might decide to throw an exception there.
+
+Although it is possible to use pattern matching, we recommend using explicit handlers, as described below.
+
+### Using explicit handlers
+
+You can also use explicit event handlers, where you define one function per event, and register them in the constructor. In that case, there's no need to override the `When` function.
+
+The syntax is simple, allowing you to add separate functions for applying each event type to the state:
+
+```csharp title="BookingState.cs"
+public record BookingState : State<BookingState> {
+    public BookingState() {
+        On<RoomBooked>(
+            (state, booked) => state with {
+                Price = new Money(booked.Price),
+                AmountPaid = new Money(0)
+            }
+        );
+
+        On<BookingImported>(
+            (state, imported) => state with {
+                Price = new Money(imported.Price),
+                AmountPaid = new Money(0)
+            }
+        );
+
+        On<BookingPaymentRegistered>(
+            (state, paid) => state with {
+                AmountPaid = state.AmountPaid + new Money(paid.AmountPaid),
+                _payments = state._payments.Add(
+                    new Payment(paid.PaymentId, new Money(paid.AmountPaid))
+                )
+            }
+        );
+    }
+
+    ImmutableArray<Payment> _payments = ImmutableArray<Payment>.Empty;
+
+    public Money Price      { get; private init; }
+    public Money AmountPaid { get; private init; }
+
+    public bool IsFullyPaid() => AmountPaid.Amount >= Price.Amount;
+
+    public bool IsOverpaid() => AmountPaid.Amount > Price.Amount;
+
+    public bool HasPayment(string paymentId) => _payments.Any(p => p.PaymentId == paymentId);
+
+    record Payment(string PaymentId, Money Amount);
+}
+```
+
+As you can see, state is immutable, and the `On` function registers a handler for the event. The handler receives the current state and the event as arguments and returns the new state instance.
+
+The sample code also shows that the state class can have some query logic, which is not related to the event handling. It can be useful to encapsulate queries in the state class so the domain logic gets only focused on making decisions based on the state.
+
+### State with typed identity
+
+Normally, you won't be interested to know what state object identity is as you'd operate within an enclosed boundary of an aggregate or a stream. For that reason, you won't need to add the identity value to the events. The identity of an object can always be derived from the stream name, as it contains the object type and the identity already.
+
+If you find it necessary to know what identity is assigned to the state object, you can use the identity-aware state, derived from `State<TId>` abstract record. The `TId` type there is a child type of the `Id` abstract record.
+
+For example, you can declare an identity-aware state type like this:
+
+```csharp
+public record BookingId(string Value) : Id(Value);
+
+public record BookingState<BookingId> {
+    public BookingState() {
+        On<RoomBooked>(...); // skipped for brevity
+    }
+}
+```
+
+The `BookingState` type will have a property named `Id` of type `BookingId`. You don't need to set it manually as it will be provided when the state object is recreated from events by the command service.
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/faq/compare.md b/docs/src/content/docs/0.15/faq/compare.md
new file mode 100644
index 000000000..c6fb6be06
--- /dev/null
+++ b/docs/src/content/docs/0.15/faq/compare.md
@@ -0,0 +1,46 @@
+---
+title: "Compare"
+description: "How Eventuous is different from others?"
+---
+
+## How is Eventuous different from other libs?
+
+You might have seen other libraries, old and new, that provide similar functionality to Eventuous. Here's how Eventuous is different:
+
+### Persistence
+
+Following EventStoreDB principles, Eventuous is build with strict global ordering in mind. It has pros and cons, and we believe that the pros outweigh the cons.
+
+In real life events happen in certain order. Naturally, some things happen at the same time, and it is literally impossible to say if two events happened at the same time or one before another. And, we also would not care, **unless** there's a causation. There are many debates on this topic out there, where the primary argument against caring for global order is that we should only care about order of events in the same stream. This is a valid point, but it's not the only one. Events across streams might have causality, and we should care about it.
+
+The problem is that causal relationship is not easy to implement, and it's often a domain concern that cannot be abstracted to a library. However, Eventuous provides a way to implement causal _ordering_ between events in different streams by enforcing global ordering.
+
+As a consequence, causal ordering is available across streams without additional complexity from the domain model side.
+
+However, this approach sets certain expectations for the underlying infrastructure. For example, EventStoreDB is a perfect match for Eventuous, as it provides the same guarantees. Other stores implemented by Eventuous provide the same guarantees but global ordering requirements might affect the performance.
+
+### Just enough abstractions
+
+Eventuous provides just enough abstractions to make it easy to use, but not too much to make it hard to understand. We believe that the best way to learn is to see how things work under the hood. That's why Eventuous is built with a clear separation of concerns, but without unnecessary abstractions.
+
+Many libs and frameworks enforce abstractions on things that should not be abstracted. Mainly, it's about so-called marker interfaces) like `IEvent` or `ICommand`. Eventuous does not enforce such interfaces, as they are not necessary for the library to work.
+
+Additionally, interfaces like `IEventHandler` are often used for things like projections, or implicit invocation of `Apply<T>` methods on aggregates. Eventuous does not use such interfaces in favour of explicit mappings of types to functions, which avoids the library to do magic behind the scenes and doesn't require to use reflections, which would be bad for performance.
+
+Eventuous uses reflections carefully and only during bootstrapping.
+
+### Latest .NET
+
+Eventuous is relatively new, and we aim keeping it up to date with the latest features of C# and .NET. The library uses ASP.NET Core native elements like configuration, hosting, and dependency injection. It allows developers to jump-start their projects without learning new concepts, at least about the bootstrapping basics.
+
+### No strong DDD focus
+
+Although Domain-Driven Design (DDD) is very useful and provides patterns that are directly applicable for event-sourced systems, there are different styles of building applications. Code patterns like Aggregate and Repository are quite old, and there's no necessity in using them everywhere. Eventuous provides a way to build event-sourced systems without enforcing DDD patterns. It's up to the developer to decide what building blocks to use.
+
+### First-class observability
+
+Eventuous implements all elements of observability like [logging](../../diagnostics/logs), [metrics](../../diagnostics/metrics), and [distributed tracing](../../diagnostics/traces).
+
+It is important to understand that observability is not only about logging and metrics. It's about understanding the system's behaviour and performance. Eventuous provides a way to trace messages across the system, which is crucial for understanding the system's behaviour. Following the current observability trends, Eventuous [integrates](../../diagnostics/opentelemetry) natively with OpenTelemetry, so applications can be configured to export traces and metrics to any APM provider that support OTLP.
+
+Particularly, each event-sourced system essentially is a distributed system, and it's important to understand how messages flow through the system. Eventuous provides a way to trace messages across the system, which is crucial for understanding the system's behaviour.
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/faq/compatibility.md b/docs/src/content/docs/0.15/faq/compatibility.md
new file mode 100644
index 000000000..75e78c372
--- /dev/null
+++ b/docs/src/content/docs/0.15/faq/compatibility.md
@@ -0,0 +1,17 @@
+---
+title: "Compatibility"
+description: "Platforms and SDKs"
+---
+
+## Only .NET 6+? Why not .NET Framework 3.5?
+
+Eventuous uses the latest features of C#, like records and advanced pattern matching. Therefore, we rely on compiler versions which support C# 11.
+
+We also aim to support the current application hosting model that only got consistent and stable in .NET 6+.
+
+Eventuous supports .NET Core 3.1, but it's not a priority. Some packages only support .NET 6 and .NET 8 as they need the latest features like minimal API. Right now, Eventuous provides packages for the following runtimes:
+
+- .NET 6
+- .NET 8
+
+Targets will be added and removed when getting out of support or when new versions get released.
diff --git a/docs/src/content/docs/0.15/faq/persistence.md b/docs/src/content/docs/0.15/faq/persistence.md
new file mode 100644
index 000000000..8876adf74
--- /dev/null
+++ b/docs/src/content/docs/0.15/faq/persistence.md
@@ -0,0 +1,15 @@
+---
+title: "Persistence"
+description: >
+    What about repositories and other questions about persistence
+---
+
+### Why you don't have repositories?
+
+The definition of the `Repository` pattern from [bliki](https://martinfowler.com/eaaCatalog/repository.html):
+
+> [Repository] Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
+
+When using Event Sourcing, the idea of having a collection-like interface for accessing domain objects might be challenging to implement. It's because we don't persist domain objects state, but their state transitions as events instead. Therefore, having a collection-like abstraction on top of an event-sourced persistence would require, essentially, to load the whole event store to memory.
+
+As Event Sourcing greatly benefits from using CQRS, the need to have a collection-like persistence abstraction also diminishes. In the command-oriented flow, you would only change the state of a single aggregate by handling one command. Therefore, you neither need a collection-like interface to load the state of a single aggregate, nor to append new events for a single aggregate to the store.
diff --git a/docs/src/content/docs/0.15/gateway/implementation.md b/docs/src/content/docs/0.15/gateway/implementation.md
new file mode 100644
index 000000000..2ff1d2fc0
--- /dev/null
+++ b/docs/src/content/docs/0.15/gateway/implementation.md
@@ -0,0 +1,81 @@
+---
+title: "Implementation"
+description: "Implementing the Gateway"
+sidebar:
+  order: 10
+---
+
+Gateway is a ready-made Eventuous construct that needs other components to work properly (subscription and producer at least). Any of subscription and producer type provided by Eventuous, as well as custom ones, can be used in a gateway.
+
+When you implement a gateway, the only things that you need to do are:
+* Provide an optional transformation and filtering function
+* Register a gateway given one subscription and one producer
+
+## Transformation
+
+One common scenario for a gateway is to distribute domain events to other systems via a message broker. However, it's not a good idea to publish domain events as-is for others to consume. By doing so, you are coupling downstream consumers to your domain model. When you decide to change your domain model, and, possibly, enrich your domain events, you force developers of downstream consumers to change their code. Effectively, you either lose the ability to change your domain model, or you are coupling downstream systems to your bounded context.
+
+That's why we strongly suggest to establish a contract-like event schema for the outside world, and keep it stable. That's also one more reason not to allow other systems to subscribe to your domain (_private_) events directly from the event store, but deploy a gateway and distribute your 
+integration and notification (_public_) events using a message broker.
+
+If you decide to revamp the public events schema, you can do it the same way as you'd publish a new API schema version. Using a gateway, you can produce multiple public events given one private event, so you can always produce different versions of the same event as a public event for the period of support for both versions. In short, using a clear private vs public event transformation you can treat integrations events schema as a versioned contract, and be free to evolve your domain (private) events as you wish.
+
+Based on the producer kind (with or without options), you can perform the transformation using a function that implements `RouteAndTransform` or `RouteAndTransform<TProducerOptions>`:
+
+```csharp
+delegate ValueTask<GatewayMessage[]> RouteAndTransform(IMessageConsumeContext context);
+delegate ValueTask<GatewayMessage<TProduceOptions>[]> RouteAndTransform<TProduceOptions>(
+    IMessageConsumeContext message
+);
+```
+
+If you prefer to do the transformation using classes, you can implement the `IGatewayTransform` interface:
+
+```csharp
+interface IGatewayTransform {
+    ValueTask<GatewayMessage[]> RouteAndTransform(IMessageConsumeContext context);
+}
+
+interface IGatewayTransform<TProduceOptions> {
+    ValueTask<GatewayMessage<TProduceOptions>[]> RouteAndTransform(
+        IMessageConsumeContext context
+    );
+}
+```
+
+As you can see, both ways require to return an array of `GatewayMessage` objects. The returned array could be empty if you don't want to produce a public event for a given private event.
+
+The `GatewayMessage` signatures are:
+
+```csharp
+record GatewayMessage(StreamName TargetStream, object Message, Metadata? Metadata);
+
+record GatewayMessage<TProduceOptions>(
+    StreamName      TargetStream,
+    object          Message,
+    Metadata?       Metadata,
+    TProduceOptions ProduceOptions
+) : GatewayMessage(TargetStream, Message, Metadata);
+```
+
+## Registration
+
+There's no other component to implement for getting a working gateway. You need to register a gateway using one subscription, one producer, and one transformation function or class.
+
+To register a gateway, use one of the `AddGateway` methods. For example, the sample application uses this gateway registration for publishing integration events to EventStoreDB integration stream:
+
+```csharp
+services
+    .AddGateway<AllStreamSubscription, AllStreamSubscriptionOptions, EventStoreProducer>(
+        "IntegrationSubscription",
+        PaymentsGateway.Transform
+    );
+```
+
+Here, `PaymentsGateway.Transform` is a transformation function that transforms private events to public events.
+
+You can use any available subscription or producer for the gateway. If the subscription needs a checkpoint store, you can either register it globally, or provide one using the subscription configuration function for the `AddGateway` method. The same function can be used for any additional subscription configuration, like partitioning.
+
+There are overloads to register a gateway using a producer with options as well. You can also provide additional functions to configure the subscription when using, for example, a specific checkpoint store. You can also register a gateway that uses the transformation class instead of a function.
+
+All of the `AddGateway` overloads also have a parameter called `awaitProduce` of type `bool` that is set to `true` by default. It only works for producers that support delayed delivery reports, like the Kafka producer. When you set it to `false`, you might get better performance of the producer, but you can get undesired consequences if the producer fails for some messages, as when the produce action is retried you might get duplicate messages produced.
diff --git a/docs/src/content/docs/0.15/gateway/index.mdx b/docs/src/content/docs/0.15/gateway/index.mdx
new file mode 100644
index 000000000..0a4f5a37f
--- /dev/null
+++ b/docs/src/content/docs/0.15/gateway/index.mdx
@@ -0,0 +1,21 @@
+---
+title: "Gateway"
+description: "Event gateway copies events between databases and brokers"
+sidebar:
+  order: 80
+---
+
+An event gateway is an engine to bridge Event Sourcing with Event-Driven Architecture (EDA). When you store events to an [event store](../persistence/event-store), you can use an event gateway to receive stored events, transform them, and distribute downstream using different transport.
+
+Scenarios where an event gateway is useful:
+* Publish transformed domain events as integration events using a broker
+* Scale out projections using a partitioned, event-based broker, such as Kafka, Amazon Kinesis, Google PubSub or Azure Event Hub
+* Backup or archive domain events in another event store or time-series database
+* Send events to an analytics store or service
+
+## How a gateway works
+
+A gateway needs three components that form a gateway event pipeline:
+* [Subscription](../subscriptions/subs-concept) to the source event store
+* [Transformation](implementation/#transformation) function that can also be used as a filter
+* [Producer](../producers) to a broker, another event store, or a database
diff --git a/docs/src/content/docs/0.15/index.mdx b/docs/src/content/docs/0.15/index.mdx
new file mode 100644
index 000000000..3092701fd
--- /dev/null
+++ b/docs/src/content/docs/0.15/index.mdx
@@ -0,0 +1,35 @@
+---
+title: Event Sourcing for .NET
+description: Production-grade Event Sourcing library implementing DDD tactical patterns.
+template: splash
+hero:
+  tagline: Production-grade Event Sourcing library for .NET, implementing DDD tactical patterns. Aggregates, command services, event stores, subscriptions, and projections — all out of the box.
+  image:
+    file: ../../../assets/logo.png
+  actions:
+    - text: Get started
+      link: /intro/
+      icon: right-arrow
+      variant: primary
+    - text: View on GitHub
+      link: https://github.com/eventuous/eventuous
+      icon: external
+      variant: minimal
+---
+
+import { Card, CardGrid } from '@astrojs/starlight/components';
+
+<CardGrid stagger>
+  <Card title="Domain modelling" icon="pencil">
+    Aggregates with state folding, strongly-typed identities, and optimistic concurrency built in.
+  </Card>
+  <Card title="Multiple event stores" icon="add-document">
+    First-class support for KurrentDB, PostgreSQL, SQL Server, and SQLite — with a common abstraction layer.
+  </Card>
+  <Card title="Subscriptions and projections" icon="setting">
+    Real-time event processing with checkpointing, consume pipes, and partitioned subscriptions.
+  </Card>
+  <Card title="Built-in diagnostics" icon="open-book">
+    OpenTelemetry tracing and metrics out of the box for full observability.
+  </Card>
+</CardGrid>
diff --git a/docs/src/content/docs/0.15/infra/elastic.md b/docs/src/content/docs/0.15/infra/elastic.md
new file mode 100644
index 000000000..29b49b407
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/elastic.md
@@ -0,0 +1,6 @@
+---
+title: "Elasticsearch"
+description: "Storing and archiving events in Elasticsearch"
+---
+
+WIP
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/infra/esdb.md b/docs/src/content/docs/0.15/infra/esdb.md
new file mode 100644
index 000000000..0f569b08b
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/esdb.md
@@ -0,0 +1,256 @@
+---
+title: "EventStoreDB"
+description: "EventStoreDB is a database for event-sourced applications"
+sidebar:
+  order: 1
+---
+
+Eventuous uses [EventStoreDB][1] as the default event store. It's a great product, and we're happy to provide first-class support for it. It's also a great product for learning about Event Sourcing and CQRS.
+
+Below, you can find Eventuous components that are implemented for EventStoreDB. 
+
+:::tip
+Remember to check [Event Store Cloud](https://www.eventstore.com/event-store-cloud).
+:::
+
+## Events persistence
+
+The `EsdbEventStore` is an implementation of `IEventStore` interface. It uses the EventStoreDB gRPC client, so the legacy TCP protocol isn't supported. Therefore, Eventuous only works with EventStoreDB 20+, which has gRPC support.
+
+The easiest way to use it is to register it in the DI container. As `EsdbEventStore` needs an EventStoreDB client as a dependency, you'd need to register the client first. The client package has DI registration extensions that allow you to register the client using a single line of code:
+
+```csharp
+services.AddEventStoreClient(connectionString);
+```
+
+The connection string usually comes from the application configuration. When running locally using Docker, you might use a connection string like:
+
+```csharp
+var connectionString = "esdb://localhost:2113?tls=false";
+```
+
+When running in production, you'd use a secure connection string, which contains a username and password. You can find more information about connection strings in the [EventStoreDB documentation][3].
+
+Further, you need to tell Eventuous to use the `EsdbEventStore` for its aggregate store. We have a simple extension that allows you to do that:
+
+```csharp
+services.AddEventStore<EsdbEventStore>();
+```
+
+When that's done, Eventuous would persist aggregates using EventStoreDB when you use the [command service](../../application/app-service).
+
+## Subscriptions
+
+EventStoreDB supports multiple [subscription](../../subscriptions/subs-concept) types, and all of them are supported by Eventuous. The main choice you'd need to make is to use [catch-up][4] or [persistent subscription][5].
+
+### All stream subscription
+
+Subscribing to all events in the store is extremely valuable. This way, you can build comprehensive read models, which consolidate information from multiple aggregates. You can also use such a subscription for integration purposes, to convert and publish integration events.
+
+:::note
+[Read more](https://zimarev.com/blog/event-sourcing/all-stream/) about the benefits of using the global event stream.
+:::
+
+For registering a subscription to `$all` stream, use `AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>` as shown below:
+
+```csharp
+builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    b => b
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>()
+);
+```
+
+Subscription options for `AllStreamSubscription` are defined in `AllStreamSubscriptionOptions` class.
+
+| Option               | Description                                                                                                                                                                                                                                                        |
+|:---------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `SubscriptionId`     | Unique subscription identifier.                                                                                                                                                                                                                                    |
+| `ThrowOnError`       | If `true`, an exception will be thrown if the subscription fails, otherwise the subscription continues to run. Default is `false`.                                                                                                                                 |
+| `EventSerilizer`     | Serializer for events, if `null` the default serializer will be used.                                                                                                                                                                                              |                                                                                                                                                                  
+| `MetadataSerilizer`  | Serializer for metadata, if `null` the default serializer will be used.                                                                                                                                                                                            |                                                                                
+| `Credentials`        | EventStoreDB user credentials. If not specified, the credentials specified in the `EventStoreClientSettings` will be used.                                                                                                                                         |                                                                              
+| `ResolveLinkTos`     | If `true`, the subscription will automatically resolve the event link to the event that caused the event. Default is `false`.                                                                                                                                      |
+| `ConcurrencyLimit`   | Maximum number of events to be processed in parallel. Default is `1`.                                                                                                                                                                                              |                                                                                             
+| `EventFilter`        | Filter for events, if `null`, the subscription will filter out system events.                                                                                                                                                                                      |                                                                                                                                                                         
+| `CheckpointInterval` | Interval between checkpoints when event filter is used. Default is `10` events. This interval tells the subscription to report the current checkpoint when the subscription doesn't receive any events for this interval because all the events were filtered out. |
+
+#### Checkpoint store
+
+`AllStreamSubscription` is a catch-up subscription that is fully managed on the client side (your application), so you need to manage the [checkpoint](../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, but in that case it will be used for all subscriptions in the application. It might be that your app has multiple subscriptions, and you want to use different checkpoint stores for each of them. In that case, you can register the checkpoint store for each subscription using `UseCheckpointStore<T>` extension of the subscription builder
+
+```csharp
+builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    b => b
+        .UseCheckpointStore<MongoCheckpointStore>()
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>()
+);
+```
+
+#### Concurrent event handlers
+
+As any catch-up subscription, subscription to `$all` runs sequentially, processing events one by one. In many cases that's enough, but sometimes you might want to speed it up, and allow parallel processing of events. To do that, you need to set the `ConcurrencyLimit` subscription option property to a value that is equal to the number of events being processed in parallel. In addition, you need to tell the subscription how to distribute events into partitions. That is needed as you rarely can tolerate processing events in a completely random order, so you can partition events using some key, and distribute them to different partitions.
+
+Here is an example of using `AllStreamSubscription` with `ConcurrencyLimit` and partitioning by stream name:
+
+```csharp
+var partitionCount = 2;
+builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    b => b
+        .Configure(cfg => cfg.ConcurrencyLimit = partitionCount)
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>()
+        .WithPartitioningByStream(partitionCount)
+);
+```
+
+You can build your own partitioning strategy by implementing the `GetPartitionKey` function:
+
+```csharp
+public delegate string GetPartitionKey(IMessageConsumeContext context);
+```
+
+and then using it in the `WithPartitioning` extension:
+
+```csharp
+builder => builder
+    .Configure(cfg => cfg.ConcurrencyLimit = partitionCount)
+    ... // add handlers
+    .WithPartitioning(partitionCount, MyPartitionFunction)
+```
+
+### Single stream subscription
+
+Although subscribing to `$all` using [`AllStreamSubscription`](#all-stream-subscription) is the most efficient way to create, for example, [read models](../../read-models/rm-concept) using all events in the event store, it is also possible to subscribe to a single stream.
+
+For example, you can subscribe to the `$ce-Booking` stream to project all events for all the aggregates of type `Booking`, and create some representation of the state of the aggregate in a queryable store.
+
+Another scenario is to subscribe to an integration stream, when you use EventStoreDB as a backend for a messaging system.
+
+For that purpose you can use the `StreamSubscription` class.
+
+For registering a subscription to a single stream, use `AddSubscription<StreamSubscription, StreamSubscriptionOptions>` as shown below:
+
+```csharp
+builder.Services.AddSubscription<StreamSubscription, StreamSubscriptionOptions>(
+    "BookingsStateProjections",
+    b => b
+        .Configure(cfg => {
+            cfg.StreamName = new StreamName("$ce-Booking");
+            cfg.ResolveLinkTos = true;
+        })
+        .AddEventHandler<BookingStateProjection>()
+);
+```
+
+Subscription options for `StreamSubscription` are defined in `StreamSubscriptionOptions` class.
+
+| Option               | Description                                                                                                                        |
+|:---------------------|:-----------------------------------------------------------------------------------------------------------------------------------|
+| `SubscriptionId`     | Unique subscription identifier.                                                                                                    |
+| `StreamName`         | Name of the stream to subscribe to.                                                                                                |
+| `ThrowOnError`       | If `true`, an exception will be thrown if the subscription fails, otherwise the subscription continues to run. Default is `false`. |
+| `EventSerilizer`     | Serializer for events, if `null` the default serializer will be used.                                                              |
+| `MetadataSerilizer`  | Serializer for metadata, if `null` the default serializer will be used.                                                            |
+| `Credentials`        | EventStoreDB user credentials. If not specified, the credentials specified in the `EventStoreClientSettings` will be used.         |
+| `ResolveLinkTos`     | If `true`, the subscription will automatically resolve the event link to the event that caused the event. Default is `false`.      |
+| `IgnoreSystemEvents` | Set to true to ignore system events. Default is `true`.                                                                            |
+| `ConcurrencyLimit`   | Maximum number of events to be processed in parallel. Default is `1`.                                                              |
+
+:::info
+At the bare minimum, you must define the stream name in the subscription options.
+:::
+
+:::caution[Link events]
+When subscribing to a stream that contains link events (for example, `$ce-` category stream), you should set the `ResolveLinkTos` option to `true` to resolve the link to the original event that is linked to the link event.
+:::
+
+#### Checkpoint store
+
+`StreamSubscription` is a catch-up subscription that is fully managed on the client side (your application), so you need to manage the [checkpoint](../../subscriptions/checkpoint). The checkpoint store configuration for stream subscriptions is identical to the one for the [`AllStreamSubscription`](#checkpoint-store).
+
+#### Concurrent event handlers
+
+The single stream subscription is identical to the `$all` stream subscription in terms of the event handlers execution. By default, all the events are processed one-by-one, but you can use the `ConcurrencyLimit` option to process multiple events in parallel.
+
+You can use the stream name partitioner when subscribing to a category (`$ce`) stream. In that case events for a single aggregate instance will always be processed sequentially, but events for different aggregate instances can be processed in parallel.
+
+Read more about concurrent event processing on the [all stream subscription](#concurrent-event-handlers) page.
+
+### Persistent subscriptions
+
+:::caution[Ordered events]
+EventStoreDB persistent subscriptions do not guarantee ordered event processing. Therefore, we only recommend using them for integration purposes (reactions).
+:::
+
+:::note
+Persistent subscription to $all stream is only supported from EventStoreDB version 21.10.0.
+:::
+
+Unlike catch-up subscriptions, persistent subscriptions are fully managed by the database server. It is also possible to have multiple consumers for the same subscription, and the events will be distributed between them. The server also manages retries when a consumer fails to acknowledge the event. Because of the retries, batched delivery, and multiple consumers, persistent subscriptions don't guarantee ordered event processing.
+
+Read more about persistent subscriptions in the [EventStoreDB documentation](https://developers.eventstore.com/server/v21.10/persistent-subscriptions.html).
+
+There are some operations that must be completed before a persistent subscription starts working, In particular, the consumer group must be created on the server before a consumer can start consuming events. Eventuous implicitly creates a consumer group if necessary. The consumer group name is the same as the subscription id.
+
+Registering a persistent subscription is very similar to registering a catch-up subscription. The only difference is that you need to use one of the `PersistentSubscription` classes instead of the `StreamSubscription` or `AllStreamSubscription` class.
+
+Here's how you set up a persistent subscription to a single stream:
+
+```csharp
+builder.Services.AddSubscription<StreamPersistentSubscription, StreamPersistentSubscriptionOptions>(
+    "PaymentIntegration",
+    b => b
+        .Configure(x => x.StreamName = PaymentsIntegrationHandler.Stream)
+        .AddEventHandler<PaymentsIntegrationHandler>()
+);
+```
+
+When setting up a persistent subscription to the `$all` stream, you don't need to specify the stream name, and you need to use the `AllPersistentSubscription` class:
+
+```csharp
+builder.Services.AddSubscription<AllPersistentSubscription, AllPersistentSubscriptionOptions>(
+    "CrossAggregateIntegration",
+    b=> b.AddEventHandler<CrossAggregateIntegrationHandler>()
+);
+```
+
+There's no need to use a checkpoint store as persistent subscription checkpoint is maintained by the server.
+
+## Producer
+
+In a prototype or small-scale production application, you can use EventStoreDB as a message broker. In that case, you can use the `EventStoreProducer` to publish events to the database. Unlike the aggregate store, [producers](../../producers) allow publishing events that aren't necessarily domain events.
+
+You can then register the `EventStoreProducer` in the DI container. As the producer needs the `EventStoreClient` or `EventStoreClientSettings` as a dependency, you need to register those as well.
+
+```csharp
+builder.Services.AddEventStoreClient("esdb://localhost:2113?tls=false");
+builder.Services.AddEventProducer<EventStoreProducer>();
+```
+
+To produce an event, the producer needs a stream name, a message, and (optionally) the message metadata:
+
+```csharp
+[EventType("TestMessage")]
+public record TestMessage(string Text);
+
+var message = new TestMessage("Hello world!");
+await producer.Produce("test-stream", message, new Metadata());
+```
+
+You can also produce multiple messages at once, but then you need to wrap each message to a `ProducedMessage` object:
+
+```csharp
+var messages = events.Select(x => new ProducedMessage(x, new Metadata()));
+await producer.Produce("test-stream", messages);
+```
+
+[1]: https://eventstore.com
+[2]: https://www.eventstore.com/event-store-cloud
+[3]: https://developers.eventstore.com/clients/grpc/
+[4]: https://developers.eventstore.com/clients/grpc/subscriptions.html
+[5]: https://developers.eventstore.com/clients/grpc/persistent-subscriptions.html
diff --git a/docs/src/content/docs/0.15/infra/kafka.md b/docs/src/content/docs/0.15/infra/kafka.md
new file mode 100644
index 000000000..0df92bc82
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/kafka.md
@@ -0,0 +1,70 @@
+---
+title: "Apache Kafka"
+description: "Producers and subscriptions for Kafka"
+---
+
+## Producer
+
+Eventuous support producing messages to Apache Kafka topics. Currently, there is no schema registry support available when using Eventuous Kafka producer, and all messages are serialized using the default serializer as JSON, or using a custom serializer in any format. The serialized payload is then sent to Kafka topics as a byte array. There's no magic byte appended to the message, so you can use any serializer you want.
+
+### Configuration
+
+The producer configuration should be provided in the `KafkaProducerOptions` record. It only has one property: `ProducerConfig` which is a `ProducerConfig` class from the `Confluent.Kafka` library.
+
+For example, you can configure and start the producer like this:
+
+```csharp
+var options = new KafkaProducerOptions(
+    new ProducerConfig { BootstrapServers = "localhost:9092" }
+);
+await using var producer = new KafkaBasicProducer(options);
+await producer.StartAsync(default);
+await producer.Produce(new StreamName(topicName), events, new Metadata());
+```
+
+You can also add the producer to the dependency injection container:
+
+```csharp
+var options = new KafkaProducerOptions(
+    new ProducerConfig { BootstrapServers = "localhost:9092" }
+);
+builder.Services.AddSingleton(options);
+builder.Services.AddProducer<KafkaBasicProducer>();
+```
+
+Because Kafka producer requires lifecycle management, it also registers as a hosted service. When using `AddProducer` extension, the producer is registered as a hosted service automatically.
+
+::: tip
+The producer does not create topics in Kafka. You need to create topics manually before using the producer.
+:::
+
+### Producing messages
+
+There are two ways to produce messages to Kafka: with or without partitioning.
+
+Partition key is provided in `KafkaProduceOptions`, which is the optional parameter of the `Produce` method. If the partition key is not provided, the message is sent to a random partition.
+
+```csharp
+// Produce withouth partitioning
+await producer.Produce(new StreamName(topicName), events, new Metadata());
+
+// Produce with partitioning
+await producer.Produce(new StreamName(topicName), events, new Metadata(), new("MyKey");
+```
+
+The `events` parameter is a list of `ProducedMessage` records. Each record contains the message payload, metadata and message id.
+
+The producer supports publishing with immediate and delayed acknowledgement. The way to produce a message from the provided list is determined by presence of `ProducedMessage.OnAck` property. If the property is not set, the message is produced with immediate acknowledgement. If the property is set, the message is produced with delayed acknowledgement, and the `OnAck` function will be called when the producer receives an acknowledgement from Kafka. If the broker doesn't acknowledge the message, the producer will call the `OnNack` function if it is set in the `ProducedMessage` record.
+
+For transmitting message details downstream, the producer sets two default message headers:
+
+* `message-type`: the type of the message as string, usually coming from the type mapper
+* `content-type`: the content type of the message, set to `application/json` when using the default serializer
+
+Additional headers are set by the user in the `Metadata` record.
+
+### Tracing
+
+The Kafka producer creates a span for the whole batch of messages, so every message will get a span id and trace id headers set to the same value for all the messages.
+
+When the batch only contains one message, the producer will also set the message type span tag.
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/infra/mongodb.md b/docs/src/content/docs/0.15/infra/mongodb.md
new file mode 100644
index 000000000..0c2f69d37
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/mongodb.md
@@ -0,0 +1,248 @@
+---
+title: "MongoDB"
+description: "MongoDB support for projections"
+sidebar:
+  order: 2
+---
+
+MongoDB is a popular document database, and Eventuous natively supports projecting events to it. In combination with Mongo [checkpoint store](../../subscriptions/checkpoint) you can comfortably use MongoDB as a queryable store for your read models.
+
+The base class for a MongoDB projection is `MongoProjection<T>` where `T` is a record derived from the `ProjectedDocument` abstract record.
+
+## Projected document
+
+The `ProjectedDocument` record has two properties: `Id`, which is used as the document id, and `Position`. The `Position` property is set by the Mongo projection implicitly when an event is projected to a document. The value set for this property is the projection position in the subscribed stream. You can use this information for addressing the [consistency concern](../../read-models/rm-concept#dealing-with-stale-data).
+
+Here is an example of a document model from the sample application:
+
+```csharp
+public record BookingDocument : ProjectedDocument {
+    public BookingDocument(string id) : base(id) { }
+
+    public string    GuestId      { get; init; }
+    public string    RoomId       { get; init; }
+    public LocalDate CheckInDate  { get; init; }
+    public LocalDate CheckOutDate { get; init; }
+    public float     BookingPrice { get; init; }
+    public float     PaidAmount   { get; init; }
+    public float     Outstanding  { get; init; }
+    public bool      Paid         { get; init; }
+}
+```
+
+You might notice that it mostly replicates the `Booking` aggregate state, and that's not the best practice, but it will serve the purpose as an example.
+
+## Dependencies
+
+The only dependency for a MongoDB projection is `IMongoDatabase` instance. One projection is expected to work with one document collection, as it is the default for mapping document models in C# to BSON models in MongoDB. The collection name is derived from the document model class, excluding the `Document` part. For example, the aforementioned `BookingDocument` model would be mapped to the `booking` collection.
+
+The dependency needs to be passed to the base class constructor, otherwise the code won't compile. Here is the constructor of a sample projection that uses the `BookingDocument` model:
+
+```csharp
+public class BookingStateProjection : MongoProjection<BookingDocument> {
+    public BookingStateProjection(IMongoDatabase database) : base(database) { 
+        // projectors will be defined here
+    }
+}
+```
+
+## Projecting events
+
+We call the functions that project individual events _projectors_. One projection class can have multiple projectors, one per event type. You cannot define more than one projector for the same event type.
+
+Projectors must be registered in the projection constructor using the `On<TEvent>` method and its overloads, where `TEvent` is the event type. The base `On<TEvent>` accepts the `ProjectTypedEvent<T, TEvent>` function instance where the delegate signature is defined like this:
+
+```csharp
+public delegate ValueTask<MongoProjectOperation<T>> ProjectTypedEvent<T, TEvent>(
+    MessageConsumeContext<TEvent> consumeContext
+) where T : ProjectedDocument where TEvent : class;
+```
+
+The function must return a value task with an instance of `MongoProjectOperation<T>` where `T` is the document model. This type is a record type defined as:
+
+```csharp
+public record MongoProjectOperation<T>(Func<IMongoCollection<T>, CancellationToken, Task> Execute);
+```
+
+As you can see, a `MongoProjectOperation` record has a single property that is a function, which receives the MongoDB collection, a cancellation token, and returns a `Task`, so it is an asynchronous function.
+
+It all sounds a bit like a Russian doll, but Eventuous provides a few helpful ways to simplify this.
+
+### Operation builders
+
+Since version 0.9.0, Eventuous allows to build an instance of `ProjectTypedEvent` function using operation builders. You can use an overload of `On<TEvent>` that accepts the builder configuration function to specify all the basic MongoDB operations supported by the Mongo C# driver. It starts by specifying what operation you want to execute (insert one or many, update one or many, etc):
+
+```csharp
+On<V1.BookingCancelled>(
+    b => b.UpdateOne
+    // more to follow
+);
+```
+
+Then, you need to add the necessary operation details. For example, for updating one or many documents you need a filter and an update definition:
+
+```csharp
+On<V1.BookingCancelled>(
+    b => b.UpdateOne
+        .Filter((ctx, doc) =>
+            doc.Bookings.Select(booking => booking.BookingId).Contains(ctx.Message.BookingId)
+        )
+        .UpdateFromContext((ctx, update) =>
+            update.PullFilter(
+                x => x.Bookings,
+                x => x.BookingId == ctx.Message.BookingId
+            )
+        )
+);
+```
+
+There are two flavours of the `Filter` function:
+- Use the native `FilterDefinitionBuilder`
+- Use the function that returns a boolean as shown in the example above
+
+Filters are required for `UpdateOne`, `UpdateMany`, `DeleteOne` and `DeleteMany` operations.
+
+When you use `UpdateOne` or `DeleteOne` you can simplify the filter further by using the `Id` function instead of `Filter`. There, you just need to provide a function to get the document id from the event:
+
+```csharp
+On<V1.BookingCancelled>(
+    b => b.UpdateOne
+        .Id(ctx => ctx.Message.BookingId)
+        .Update(...)
+);
+```
+
+The `Id` function will build a filter for the document identity to be equal the given value from the context.
+
+Naturally, for deletions you don't need to specify anything else that the filter using either one of the `Filter` functions or the `Id` function (for `DeleteOne`).
+
+Both `UpdateOne` and `UpdateMany` requires to specify the update itself. There are two flavours of the `Update` function that you can use: synchronous and asynchronous. The synchronous one is the most frequently used, and it is shown in the example above. It only uses the values from the event to build an update operation, and we recommend doing that only. However, you might get into a situation when you need to get data from somewhere else. In that case, you can use the asynchronous version:
+
+```csharp
+On<V1.BookingCancelled>(
+    b => b.UpdateOne
+        .Id(ctx => ctx.Message.BookingId)
+        .Update(async (evt, update) =>
+            var missingData = await GetDataFromElsewhere();
+            update.Set(x => x.Somedata, missingData);
+        )
+);
+```
+
+For inserting documents we recommend using updates, and the default update option is set to allow upserts. This way, you don't need to care if you are accidentally (or intentionally) replay historical events over the existing collection.
+
+You can still use the insert operation using `InsertOne` or `InsertMany` builders. In that case, you don't need a filter not an update. All you need is to provide a way to create a projected document instance from the event using the `Document` function. There are, again, two flavours of it - synchronous (preferred) and asynchronous (to get more data elsewhere). For example:
+
+```csharp
+On<V1.RoomBooked>(b => b.InsertOne.Document(ctx => new BookingDocument(...)));
+```
+
+For `InsertMany` operation you need to use the `Documents` function that should return a list of documents to insert.
+
+Finally, you can configure each of those operations by using the `Configure` function. It receives the options instance for each operation (`InsertOneOptions`, `InsertManyOptions`, etc) and can change its properties. In most cases, Eventuous uses the default options. However, as mentioned previously, update options are configured to allow upserts.
+
+### Simplified updates
+
+As the update operation is the most frequent one, Eventuous provides shortcuts for defining `UpdateOne` operations. These are overloads of the `On<TEvent` function again, where the first parameter is either a filter builder function or a function to get the document id, and the second parameter is a function to build the update.
+
+For example:
+
+```csharp
+On<V1.PaymentRecorded>(
+    ctx => ctx.Message.BookingId,
+    (ctx, update) => update.Set(x => x.Outstanding, ctx.Message.Outstanding)
+);
+```
+
+## Sample
+
+Here is a full example from the sample application:
+
+```csharp
+public class BookingStateProjection : MongoProjection<BookingDocument> {
+    public BookingStateProjection(IMongoDatabase database) : base(database) {
+        On<V1.RoomBooked>(stream => stream.GetId(), HandleRoomBooked);
+
+        On<V1.PaymentRecorded>(
+            b => b
+                .UpdateOne
+                .DefaultId()
+                .Update((evt, update) =>
+                    update.Set(x => x.Outstanding, evt.Outstanding)
+                )
+        );
+
+        On<V1.BookingFullyPaid>(b => b
+            .UpdateOne
+            .DefaultId()
+            .Update((_, update) => update.Set(x => x.Paid, true))
+        );
+    }
+
+    static UpdateDefinition<BookingDocument> HandleRoomBooked(
+        IMessageConsumeContext<V1.RoomBooked> ctx, 
+        UpdateDefinitionBuilder<BookingDocument> update
+    ) {
+        var evt = ctx.Message;
+
+        return update.SetOnInsert(x => x.Id, ctx.Stream.GetId())
+            .Set(x => x.GuestId, evt.GuestId)
+            .Set(x => x.RoomId, evt.RoomId)
+            .Set(x => x.CheckInDate, evt.CheckInDate)
+            .Set(x => x.CheckOutDate, evt.CheckOutDate)
+            .Set(x => x.BookingPrice, evt.BookingPrice)
+            .Set(x => x.Outstanding, evt.OutstandingAmount);
+    }
+}
+```
+
+Here, the projector for `RoomBooked` is moved to a separate function as it's too verbose.
+
+Another example also uses the operation builders:
+
+```csharp
+using Eventuous.Projections.MongoDB;
+using MongoDB.Driver;
+using static Bookings.Domain.Bookings.BookingEvents;
+
+namespace Bookings.Application.Queries;
+
+public class MyBookingsProjection : MongoProjection<MyBookings> {
+    public MyBookingsProjection(IMongoDatabase database) : base(database) {
+        On<V1.RoomBooked>(b => b
+            .UpdateOne
+            .Id(ctx => ctx.Message.GuestId)
+            .UpdateFromContext((ctx, update) =>
+                update.AddToSet(
+                    x => x.Bookings,
+                    new MyBookings.Booking(ctx.Stream.GetId(),
+                        ctx.Message.CheckInDate,
+                        ctx.Message.CheckOutDate,
+                        ctx.Message.BookingPrice
+                    )
+                )
+            )
+        );
+
+        On<V1.BookingCancelled>(
+            b => b.UpdateOne
+                .Filter((ctx, doc) => doc.Bookings
+                        .Select(booking => booking.BookingId)
+                        .Contains(ctx.Stream.GetId())
+                )
+                .UpdateFromContext((ctx, update) =>
+                    update.PullFilter(
+                        x => x.Bookings,
+                        x => x.BookingId == ctx.Stream.GetId()
+                    )
+                )
+        );
+    }
+}
+```
+
+## Registering projections
+
+MongoDB projection is an event handler, so it can be added to a subscription using the `AddEventHandler` extension of the subscription builder.
+
+You can find examples of adding handlers to subscriptions in the [subscription documentation](../../subscriptions/sub-base/#registration).
diff --git a/docs/src/content/docs/0.15/infra/mssql.md b/docs/src/content/docs/0.15/infra/mssql.md
new file mode 100644
index 000000000..9e5d8a21f
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/mssql.md
@@ -0,0 +1,211 @@
+---
+title: "Microsoft SQL Server"
+description: "Supported Microsoft SQL Server infrastructure"
+sidebar:
+  order: 4
+---
+
+Microsoft SQL Server is a popular choice for storing queryable application data. Many organizations that use .NET as their preferred stack also use SQL Server.
+
+Eventuous supports SQL Server as an event store and also allows subscribing to the global event log and to individual streams using catch-up subscriptions.
+
+## Data model
+
+Eventuous uses a single table to store events. The table name is `Messages`. In addition, another table called `Streams` is used to control the stream existence, and store the last event number for each stream. In the `Messages` table, events and metadata are stored as `NVARCHAR(max)` columns. The table schema is as follows:
+
+```sql
+MessageId      UNIQUEIDENTIFIER      NOT NULL,
+MessageType    NVARCHAR(128)         NOT NULL,
+StreamId       INT                   NOT NULL,
+StreamPosition INT                   NOT NULL,
+GlobalPosition BIGINT IDENTITY (0,1) NOT NULL,
+JsonData       NVARCHAR(max)         NOT NULL,
+JsonMetadata   NVARCHAR(max),
+Created        DATETIME2
+```
+
+For subscriptions, Eventuous adds a table called `Checkpoints` that stores the last processed event number for each subscription. It is then used by the checkpoint store implementation for SQL Server.
+
+## Event persistence
+
+Before using SQL Server as an event store, you need to register the SQL Server-based event store implementation.
+For that to work, you'd also need to register an SQL Sever connection detail used to create connections to the database.
+Eventuous provides a few overloads for `AddEventuousSqlServer` registration extension to do that.
+
+One way to register the connection details is to provide a connection string and, optionally, the schema name:
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousSqlServer(connectionString, "mySchema", true);
+```
+
+If the schema name is not provided, the default schema name (`eventuous`) will be used.
+
+Another way to register the connection details is by using configuration options. For example, you can add the following to the settings file:
+
+```json title="appSettings.json"
+{
+  "SqlServerStore": {
+    "Schema": "mySchema",
+    "ConnectionString": "Server=127.0.0.1,57456;Database=master;User Id=sa;Password=password;TrustServerCertificate=True",
+    "InitializeDatabase": true
+  }
+}
+```
+
+Then, use the configuration section to register the connection details:
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousSqlServer(
+    builder.Configuration.GetSection("SqlServerStore")
+);
+```
+
+The `InitializeDatabase` setting tells Eventuous if it needs to create the schema. If you create the schema in a separate migration application, set this setting to `false`. If the schema cannot be found, and the `InitializeDatabase` setting is set to `false`, the application will fail to start.
+
+Next, you need to register the SQL Server event store:
+
+```csharp
+builder.Services.AddEventStore<SqlServerStore>();
+```
+
+When that's done, Eventuous will use SQL Server for persistence in command services.
+
+:::note
+At this moment, the SQL Server event store implementation doesn't support stream truncation.
+:::
+
+## Subscriptions
+
+Eventuous supports two types of subscriptions to SQL Server: global and stream. The global subscription is a catch-up subscription, which means that it reads all events from the beginning of the event log. The stream subscription is also a catch-up subscription, but it only reads events from a specific stream.
+
+Both subscription types use continuous polling to check for new events.
+
+### Registering subscriptions
+
+Registering a global log subscription is similar to [EventStoreDB](../esdb#all-stream-subscription). The only difference is the subscription and the options types:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqlServerAllStreamSubscription, SqlServerAllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    b => b
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>();
+);
+```
+
+When you register a subscription to a single stream, you need to configure the subscription options to specify the stream name:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqlServerStreamSubscription, SqlServerStreamSubscriptionOptions>(
+    "StreamSubscription",
+    b => b
+        .Configure(x => x.StreamName = "my-stream")
+        .AddEventHandler<StreamSubscriptionHander>()
+);
+```
+
+As subscriptions use the SQL Server connection details for opening the connection, there's no need to register additional dependencies apart from calling `AddEventuousSqlServer` as described in [event persistence](#event-persistence) section above.
+
+### Checkpoint store
+
+Catch-up subscriptions need a [checkpoint](../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, and it will be used for all subscriptions in the application.
+
+Remember to store the checkpoint in the same database as the read model.
+For example, if you use Postgres as an event store, and project events to read models in MongoDB, you need to use the `MongoCheckpointStore`.
+Eventuous also has a checkpoint store implementation for SQL Server (`SqlServerCheckpointStore`), which you can use if you project events to SQL Server.
+
+When using the SQL Server checkpoint store, you can register it using a dedicated extension function:
+
+```csharp
+builder.Services.AddSqlServerCheckpointStore();
+```
+
+This registration function will use the schema name provided when you register the connection details using `AddEventuousSqlServer`.
+If checkpoints need to be stored in another SQL Server instance, database, or schema, you'd need to register an instance of `SqlServerCheckpointStoreOptions` to configure that:
+
+```csharp
+builder.Services.AddSingleton(
+    new SqlServerCheckpointStoreOptions(anotherConnectionString, anotherSchema)
+);
+builder.Services.AddSqlServerCheckpointStore();
+```
+
+When you also plan to use a different SQL Server database (not the one where events are stored) for both checkpoints and read models,
+you can override the `SqlServerConnectionOptions` that are used by both checkpoint store and projectors (see below). It _must_ be done before calling `AddEventuousSqlServer`.
+
+```csharp
+builder.Services.AddSingleton(
+    new SqlServerCheckpointStoreOptions(anotherConnectionString, anotherSchema)
+);
+builder.Services.AddSqlServerCheckpointStore();
+builder.Services.AddEventuousSqlServer(
+    builder.Configuration.GetSection("SqlServerStore")
+);
+```
+
+Connection details from `SqlServerConnectionOptions` are used by default by the checkpoint store and projectors.
+
+### Projections
+
+You can use SQL Server both as an event store and as a read model store. In that case, you can use the same connection factory for both the event store, the checkpoint store, and the projector.
+
+Eventuous provides a simple projector base class, which allows you to emit SQL statements for the events you want to project, and the projector will execute them.
+
+Consider the following table schema for the query model:
+
+```sql
+IF OBJECT_ID('__schema__.Bookings', 'U') IS NULL
+BEGIN
+  CREATE TABLE __schema__.Bookings (
+    BookingId VARCHAR(1000) NOT NULL PRIMARY KEY,
+    CheckinDate DATETIME2,
+    Price NUMERIC(10,2)
+  );
+END
+```
+
+You can project the `BookingImported` event to this table using a simple projector:
+
+```csharp title="ImportingBookingsProjector.cs"
+public class ImportingBookingsProjector : SqlServerProjector {
+    public ImportingBookingsProjector(SqlServerConnectionOptions options) : base(options) {
+        var insert = $"""
+                      INSERT INTO {schemaInfo.Schema}.Bookings 
+                      (BookingId, CheckinDate, Price) 
+                      VALUES (@BookingId, @CheckinDate, @Price)
+                      """;
+
+        On<BookingEvents.BookingImported>(
+            (connection, ctx) =>
+                Project(
+                    connection,
+                    insert,
+                    new SqlParameter("@BookingId", ctx.Stream.GetId()),
+                    new SqlParameter("@CheckinDate", ctx.Message.CheckIn.ToDateTimeUnspecified()),
+                    new SqlParameter("@Price", ctx.Message.Price)
+                )
+        );
+    }
+}
+```
+
+There, `Project` is a small helper function that creates a command from a given connection, sets the command type to `Text`, assigns the given SQL statement, and adds parameters to the command. It then returns the command, so it can be executed by the projector.
+
+You can then register the projector as a subscription handler:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqlServerAllStreamSubscription, SqlServerAllStreamSubscriptionOptions>(
+    "ImportedBookingsProjections",
+    b => b
+        .UseCheckpointStore<SqlServerCheckpointStore>()
+        .AddEventHandler<ImportingBookingsProjector>();
+);
+```
+
+:::note
+You only need to explicitly specify the subscription checkpoint store with `UseCheckpointStore` if your application uses different checkpoint stores for different subscriptions.
+At this moment, there is no way to use different checkpoint store options for each subscription in the same application, they will all use the same `SqlServerCheckpointStoreOptions` or `SqlServerConnectionOptions`.
+:::
+
+Note that the `insert` operation in the projection is not idempotent, so if the event is processed twice because there was a failure, the projector will throw an exception. It would not be an issue when the subscription uses the default setting that tells it not to stop when the handler fails. If you want to ensure that failures force the subscription to throw, you can change the subscription option `ThrowOnError` to `true`, and make the operation idempotent by using "insert or update".
+Microsoft SQL Server is a popular choice for storing queryable application data. Many organizations that use .NET as their preferred stack also use SQL Server.
diff --git a/docs/src/content/docs/0.15/infra/postgres.md b/docs/src/content/docs/0.15/infra/postgres.md
new file mode 100644
index 000000000..10ef3081f
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/postgres.md
@@ -0,0 +1,177 @@
+---
+title: "PostgreSQL"
+description: "Supported PostgreSQL infrastructure"
+sidebar:
+  order: 3
+---
+
+PostgreSQL is a powerful, open source object-relational database system with over 30 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance. [source](https://www.postgresql.org/).
+
+Eventuous supports Postgres as an event store and also allows subscribing to the global event log and to individual streams using catch-up subscriptions.
+
+## Data model
+
+Eventuous uses a single table to store events. The table name is `messages`. In addition, another table called `streams` is used to control the stream existence, and store the last event number for each stream. In the `messages` table, events and metadata are stored as JSONB columns. The table schema is as follows:
+
+```sql
+message_id      uuid,
+message_type    varchar not null,
+stream_id       integer not null,
+stream_position integer not null,
+global_position bigint primary key generated always as identity, 
+json_data       jsonb not null,
+json_metadata   jsonb,
+created         timestamp not null,
+```
+
+In theory, it allows you to execute queries across events using the JSONB query syntax of Postgres SQL dialect.
+
+For subscriptions, Eventuous adds a table called `checkpoints` that stores the last processed event number for each subscription. It is then used by the checkpoint store implementation for Postgres.
+
+## Event persistence
+
+Before using Postgres as an event store, you need to register the Postgres-based event store implementation.
+For that to work, you'd also need to register a Postgres data source, which is used to create connections to the database.
+Eventuous provides a few overloads for `AddEventuousPostgres` registration extension to do that.
+
+One way to register the data source is to provide a connection string and, optionally, the schema name:
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousPostgres(connectionString, "mySchema");
+```
+
+If the schema name is not provided, the default schema name (`eventuous`) will be used.
+
+Another way to register the data source is by using configuration options. For example, you can add the following to the settings file:
+
+```json title="appSettings.json"
+{
+  "PostgresStore": {
+    "Schema": "mySchema",
+    "ConnectionString": "Host=localhost;Username=postgres;Password=secret;Database=mydb;",
+    "InitializeDatabase": true
+  }
+}
+```
+
+Then, use the configuration section to register the data source:
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousPostgres(
+    builder.Configuration.GetSection("PostgresStore")
+);
+```
+
+The `InitializeDatabase` setting tells Eventuous if it needs to create the schema. If you create the schema in a separate migration application, set this setting to `false`. If the schema cannot be found, and the `InitializeDatabase` setting is set to `false`, the application will fail to start.
+
+Next, you need to register the Postgres event store:
+
+```csharp
+builder.Services.AddEventStore<PostgresStore>();
+```
+
+When that's done, Eventuous will use Postgres for persistence in command services.
+
+## Subscriptions
+
+Eventuous supports two types of subscriptions to Postgres: global and stream. The global subscription is a catch-up subscription, which means that it reads all events from the beginning of the event log. The stream subscription is also a catch-up subscription, but it only reads events from a specific stream.
+
+Both subscription types use continuous polling to check for new events. We don't use the notification feature of Postgres.
+
+### Registering subscriptions
+
+Registering a global log subscription is similar to [EventStoreDB](../esdb#all-stream-subscription). The only difference is the subscription and the options types:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<PostgresAllStreamSubscription, PostgresAllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    b => b
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>();
+);
+```
+
+When you register a subscription to a single stream, you need to configure the subscription options to specify the stream name:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<PostgresStreamSubscription, PostgresStreamSubscriptionOptions>(
+    "StreamSubscription",
+    b => b
+        .Configure(x => x.StreamName = "my-stream")
+        .AddEventHandler<StreamSubscriptionHander>()
+);
+```
+
+As subscriptions use a Postgres data source for opening the connection, there's no need to register additional dependencies apart from calling `AddEventuousPostgres` as described in [event persistence](#event-persistence) section above.
+
+### Checkpoint store
+
+Catch-up subscriptions need a [checkpoint](../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, and it will be used for all subscriptions in the application.
+
+Remember to store the checkpoint in the same database as the read model. For example, if you use Postgres as an event store, and project events to read models in MongoDB, you need to use the `MongoCheckpointStore`. Eventuous also has a checkpoint store implementation for Postgres (`PostgresCheckpointStore`), which you can use if you project events to Postgres.
+
+When using the Postgres checkpoint store, you can register it using a dedicated extension function:
+
+```csharp
+builder.Services.AddPostgresCheckpointStore();
+```
+
+This registration function will use the schema name provided when you register the data source using `AddEventuousPostgres`.
+
+### Projections
+
+You can use Postgres both as an event store and as a read model store. In that case, you can use the same connection factory for both the event store, the checkpoint store, and the projector.
+
+Eventuous provides a simple projector base class, which allows you to emit SQL statements for the events you want to project, and the projector will execute them.
+
+Consider the following table schema for the query model:
+
+```sql
+create table if not exists myschema.bookings (
+    booking_id varchar(1000) not null primary key,
+    checkin_date timestamp,
+    price numeric(10,2)
+);
+```
+
+You can project the `BookingImported` event to this table using a simple projector:
+
+```csharp title="ImportingBookingsProjector.cs"
+public class ImportingBookingsProjector : PostgresProjector {
+    public ImportingBookingsProjector(NpgsqlDataSource dataSource) : base(dataSource) {
+        const string insert = @"insert into myschema.bookings 
+            (booking_id, checkin_date, price) 
+            values (@booking_id, @checkin_date, @price)";
+
+        On<BookingEvents.BookingImported>(
+            (connection, ctx) => 
+                Project(
+                    connection,
+                    insert,
+                    new NpgsqlParameter("@booking_id", ctx.Stream.GetId()),
+                    new NpgsqlParameter("@checkin_date", ctx.Message.CheckIn.ToDateTimeUnspecified()),
+                    new NpgsqlParameter("@price", ctx.Message.Price)
+                )
+        );
+    }
+}
+```
+
+There, `Project` is a small helper function that creates a command from a given connection, sets the command type to `Text`, assigns the given SQL statement, and adds parameters to the command. It then returns the command, so it can be executed by the projector.
+
+You can then register the projector as a subscription handler:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<PostgresAllStreamSubscription, PostgresAllStreamSubscriptionOptions>(
+    "ImportedBookingsProjections",
+    b => b
+        .UseCheckpointStore<PostgresCheckpointStore>()
+        .AddEventHandler<ImportingBookingsProjector>();
+);
+```
+
+:::note
+You only need to explicitly specify the subscription checkpoint store with `UseCheckpointStore` if your application uses different checkpoint stores for different subscriptions.
+At this moment, there is no way to use different checkpoint store options for each subscription in the same application, they will all use the same `PostgresCheckpointStoreOptions`.
+:::
+
diff --git a/docs/src/content/docs/0.15/infra/pubsub.md b/docs/src/content/docs/0.15/infra/pubsub.md
new file mode 100644
index 000000000..b70ff7050
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/pubsub.md
@@ -0,0 +1,102 @@
+---
+title: "Google PubSub"
+description: "Producers and subscriptions for Google Pub/Sub"
+sidebar:
+  order: 6
+---
+
+Pub/Sub is an asynchronous and scalable messaging service that decouples services producing messages from services processing those messages. Learn more about Pub/Sub in GCP [documentation](https://cloud.google.com/pubsub/docs/overview).
+
+Eventuous supports producing and consuming messages using Google Pub/Sub. Use the `Eventuous.GooglePubSub` NuGet package to get started.
+
+## Producer
+
+The `GooglePubSubProducer` class allows you to produce messages to any topic in a GCP project. When creating an instance of the producer, you need to provide the project id and, optionally, configure the client using the `ConfigureClient` delegate. 
+
+The `CreateTopic` option tells the producer to create a topic if it does not exist. Creating a topic is a one-time operation, so you can set this option to `false` after the topic is created. Often, you would have a separate process that creates topics and subscriptions, so the `CreateTopic` option is set to `false` by default.
+
+```csharp
+// Using options
+var producer = new GooglePubSubProducer(
+    new PubSubProducerOptions {
+        ProjectId       = "my-gcp-project",
+        ConfigureClient = b => b.EmulatorDetection = EmulatorDetection.EmulatorOrProduction,
+        CreateTopic     = true
+    }
+);
+```
+
+You can register the producer in the service collection using the `AddProducer` extension method. It's recommended to go that way because Google Pub/Sub producer needs to be started and shut down following the application lifecycle, which is done automatically when you use the `AddProducer` registration helper.
+
+Behind the scenes, the producer will create a separate Pub/Sub client instance per topic, as the Pub/Sub API only allows using one client to work with a single topic. The producer will cache the client instances, so you don't need to worry about creating too many clients.
+
+Producing messages is done using the `Produce` method. You can produce a single message or a batch of messages. The `Produce` method returns a `Task` that completes when the message is produced.
+
+```csharp
+await producer.Produce("my-topic", new MyMessage { ... });
+```
+
+It's also possible to add metadata to the produced message, which will be transferred as a set of headers. In addition, you can add the ordering key option, so you get messages with the same ordering keys consumed in the same order.
+
+```csharp
+var message = new MyMessage { ... };
+var metadata = new Metadata { ["key"] = "value" };
+await producer.Produce("my-topic", message, metadata, new PubSubProduceOptions { OrderingKey = message.TenantId });
+```
+
+## Subscription
+
+Eventuous allows you to consume messages from Google Pub/Sub, which are published by other services using the Eventuous Pub/Sub producer. Theoretically, it can also consume messages from other producers, but it expects the message to have the `eventType` and `contentType` attributes set, which might not be the case for other producers. However, if an external producer sets some attributes that can be used for the event type and content type, you can override the default attribute names in subscription options.
+
+Normally, you'd add the subscription to the service collection using `AddSubscription` extension method, as any other Eventuous subscription.
+
+```csharp
+builder.Services.AddSubscription<GooglePubSubSubscription, PubSubSubscriptionOptions>(
+    "pubsub-subscription",
+    b => b
+        .Configure(
+            x => {
+                x.ProjectId          = "my-gcp-project";
+                x.TopicId            = "my-topic";
+                x.CreateSubscription = true;
+            }
+        )
+        .AddEventHandler<TestHandler>()
+);
+```
+
+Similarly to the producer, the Eventuous subscription can create a Pub/Sub subscription if it does not exist. Creating a subscription is a one-time operation, so you can set this option to `false` after the subscription is created. Often, you would have a separate process that creates topics and subscriptions, so the `CreateSubscription` option is set to `false` by default. 
+
+If you expect to consume messages from non-Eventuous producers that provide event type and content type information in message attributes, but those attribute names don't match Eventuous conventions, you can override those attribute names in subscription options.
+
+```csharp
+options.Attributes = new PubSubAttributes {
+    EventType   = "event-type",
+    ContentType = "content-type"
+};
+```
+
+## Cloud Run subscription
+
+Google Pub/Sub messages can be used as Cloud Run triggers. Eventuous supports a lightweight subscription that can be used with the Cloud Run trigger. Use the `Eventuous.GooglePubSub.CloudRun` NuGet package to use it.
+
+Essentially, the Cloud Run subscription creates an HTTP endpoint conforming the Pub/Sub trigger API. It allows your application to receive Pub/Sub messages as HTTP requests.
+
+Cloud Run subscription set up is the same as for any other subscription, but it requires one additional step to map the HTTP endpoint.
+
+```csharp
+builder.Services.AddSubscription<CloudRunPubSubSubscription, CloudRunPubSubSubscriptionOptions>(
+    "WebhookEvents",
+    b => {
+        b.Configure(o => o.TopicId = "webhook-events"); // Topc id is not used except for popualing the stream name
+        b.AddEventHandlerWithRetries<WebhookEventHandler>(Policy.Handle<Exception>().RetryAsync(3));
+    }
+);
+
+var app = builder.Build();
+app.MapCloudRunPubSubSubscription("/");
+```
+
+The `MapCloudRunPubSubSubscription` extension method maps the subscription HTTP endpoint to the specified path. The path you provide there must match the path of your Cloud Run trigger for Pub/Sub, which you specified as the push endpoint. The push endpoint URL should be composed of your Cloud Run workload URL, combined with the path configured by `MapCloudRunPubSubSubscription`.  Root path is the default value.
+
+Read mode about configuring push subscriptions in the [Google Cloud Run documentation](https://cloud.google.com/run/docs/triggering/pubsub-push#create-push-subscription).
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/infra/rabbitmq.md b/docs/src/content/docs/0.15/infra/rabbitmq.md
new file mode 100644
index 000000000..1e0535b58
--- /dev/null
+++ b/docs/src/content/docs/0.15/infra/rabbitmq.md
@@ -0,0 +1,159 @@
+---
+title: "RabbitMQ"
+description: "Producers and subscriptions for RabbitMQ"
+sidebar:
+  order: 5
+---
+
+## Introduction
+
+RabbitMQ is a popular message broker, and it can serve as a great integration infrastructure for communicating 
+between services. Eventuous supports using RabbitMQ messaging with [producers](../../producers) for producing messages 
+and [subscriptions](../../subscriptions/subs-concept) for consuming messages.
+
+Eventuous producer for RabbitMQ publishes messages to _exchanges_.
+An exchange can be considered similar to topics in other message brokers like Kafka or Google Pub/Sub, but, unlike topics, those messages are not persistent.
+Messages published to an exchange are distributed to queues that _bound_ (subscribed) to the exchange.
+When an exchange doesn't have any bindings, all the messages published to that exchange disappear.
+
+To make RabbitMQ messaging work, you need to have exchanges and queues that bind to those exchanges. Eventuous creates an exchange by default if it doesn't exist when producing and consuming messages.
+
+When using RabbitMQ for integration between services, the usual pattern is to have one exchange per service. Alternatively, one exchange can be used for messages about one logical topic like aggregate type or stream category.
+
+## Producer
+
+Eventuous RabbitMQ producer works the same way as any other message producer. It allows you to publish messages to RabbitMQ exchanges. Those messages can then be consumed by services that use Eventuous RabbitMQ subscriptions. You can also use other messaging libraries to consume messages as Eventuous doesn't manipulate sent messages in any way.
+
+### Configuration
+
+RabbitMQ producer's constructor requires the connection factory argument. When using the default ASP.NET Core dependency injection, you'd register the connection factory instance in the DI container as part of the bootstrap code. At the bare minimum, you need a RabbitMQ connection string to create a connection factory instance:
+
+```csharp
+builder.Services.AddSingleton(
+    new ConnectionFactory {
+        Uri = new Uri(rabbitMqConnectionString)
+    }
+); 
+```
+
+When that's done, you can register the producer by using `AddProducer` extension provided by Eventuous:
+
+```csharp
+builder.Services.AddProducer<RabbitMqProducer>();
+```
+
+As the producer will create an exchange when it publishes a message, but the exchange doesn't exist, you can inform the producer how to configure those new exchanges. To do it, you can register or supply an instance of `RabbitMqExchangeOptions`. Available options are:
+
+| Option       | Description                                         | Default value |
+|--------------|-----------------------------------------------------|---------------|
+| `Type`       | Exchange type                                       | `Fanout`      |
+| `Durable`    | If the messages should be stored on disk            | `true`        |
+| `AutoDelete` | If the exchange should disappear when it's not used | `false`       |
+
+We recommend using the default exchange options, unless you want to use [routing keys][3] because fan-out exchanges don't support routing. Use exchange type `Direct` or `Topic` if you need to use RabbitMQ routing features.
+
+### Producing messages
+
+The producer publishes messages to a RabbitMQ exchange where the exchange name is the `streamName` parameter value.
+
+When you tell the producer to publish a message to an exchange, it will check if the exchange exists. If the exchange doesn't exist, the producer will create one using the exchange options described above. This check only happens once per service lifetime, so it doesn't affect performance.
+
+As the RabbitMQ producer implements the same `IProducer` interface as any other Eventuous producer, it has the same API as described on the [Producers](../../producers/implementation) page.
+
+It's possible to tune the producer's behaviour when producing messages by supplying an optional produce option. For RabbitMQ, those options are represented by the `RabbitMqProduceOptions` record with the following properties:
+
+| Option           | Description                                                                      |
+|------------------|----------------------------------------------------------------------------------|
+| `AppId`          | Application name                                                                 |
+| `Expiration`     | Time-to-live for the message in milliseconds ([read more][2])                    |
+| `Persisted`      | If the message should be persisted on disk, default is `true`                    |
+| `Priority`       | Message priority, from 0 to 9                                                    |
+| `RoutingKey`     | [Routing key][3] of the message, doesn't work with fan-out exchanges             |
+
+When the produced message has metadata, all metadata values will be converted to message headers. Subscriptions will restore headers back to metadata. If message metadata contains a correlation id (`eventuous.correlation-id` key), the value will be added to the RabbitMQ message correlation id property.
+
+## Subscriptions
+
+Eventuous supports consuming messages from RabbitMQ using [subscriptions](../../subscriptions/subs-concept).
+
+### Configuration
+
+As any other subscription, it can be added to the Di container using `AddSubscription` extension:
+
+```csharp
+builder.Services.AddSubscription<RabbitMqSubscription, RabbitMqSubscriptionOptions>(
+    "PaymentsIntegration",
+    b => b
+        .Configure(cfg => cfg.Exchange = "payments")
+        .AddEventHandler<PaymentsHandler>()
+);
+```
+
+The `Exchange` configuration property is mandatory as the subscription needs to know where it should consume messages from. Also, the subscription has a mandatory dependency on `ConnectionFactory`, so you'd need to register it in the container as described in the [producer configuration](#configuration) section above.
+
+For consuming messages, the subscription needs a queue bound to the specified exchange. By default, the subscription id is used as the queue name. You can override the queue name by specifying an alternative value using `QueueOptions.Queue` property of the subscription options.
+
+Besides the queue name, it's possible to configure the subscription with RabbitQ-specific parameters. Those include queue options, exchange options, and binding options. Eventuous provides default values for all those, so usually you would not need to change those. One option that likely should be overridden is the concurrency limit value, which is set to `1` by default. As RabbitMQ doesn't guarantee message ordering anyway, you can speed up message processing by increasing the concurrency limit, so the subscription can consume messages in parallel. Eventuous will also adjust the prefetch count to accommodate for increased number of consumers, if necessary.
+
+As mentioned previously, RabbitMQ messages are published to an exchange and consumed from a queue bound to that exchange. When the subscription starts, it makes sure that both the exchange and the queue exist, and the queue is bound to the exchange. If you start producing messages to an exchange created by the producer before starting the subscription at least once, and there's no queue and binding created upfront, those messages will be dropped. As long as the exchange has a binding to a subscription queue, the messages will be kept in the queue until consumed. Therefore, we recommend starting the subscription before producing messages.
+
+RabbitMQ subscriptions can be configured using the following options:
+
+| Option             | Description                                                                                        |
+|--------------------|----------------------------------------------------------------------------------------------------|
+| `Exchange`         | Exchange name that the subscription binds to                                                       |
+| `FailureHandler`   | Function to handle message processing errors, described [below](#error-handling)                   |
+| `ExchangeOptions`  | Exchange options (see Producer configuration above)                                                |
+| `QueueOptions`     | Subscription queue options (see below)                                                             |
+| `BindingOptions`   | Options for the binding between the exchange and the queue (see below)                             |
+| `ConcurrencyLimit` | The number of parallel consumers, default is one                                                   |
+| `PrefetchCount`    | The number of [in-flight messages][1] per consumer, default is concurrency limit multiplied by two |
+
+:::note[Exchange configuration]
+Please remember that both the producer and the subscription can create the exchange, depending on which initiates first.
+In case the exchange options set by the producer and the subscription are different, the exchange will not undergo any updates.
+It is important to note that exchange options are only taken into account at the time of exchange creation.
+:::
+
+:::note[Queue and binding configuration]
+Both the queue and the binding are only applied when those elements are created.
+Any changes to the queue and bindings that happen afterward won't trigger updating queues and bindings.
+You can still update those using RabbitMQ management API.
+:::
+
+For configuring the subscription queue, the following options are available in `RabbitMqQueueOptions`:
+
+| Name         | Description                                                                       |
+|--------------|-----------------------------------------------------------------------------------|
+| `Queue`      | Overriders the default queue name, which is set to subscription id by default     |
+| `AutoDelete` | Default is `false`, so the queue will survive restarts                            |
+| `Exclusive`  | Default is `false`, change it if you want to only have a single consumer instance |
+| `Durable`    | Default is `true`, so the queue will be persisted on disk                         |
+
+Finally, you can configure exchange-to-queue binding using `RabbitMqBindingOptions`:
+
+| Name         | Description                                                                       |
+|--------------|-----------------------------------------------------------------------------------|
+| `RoutingKey` | Optional [routing key][3] for the binding, it doesn't work with fan-out exchanges |
+
+If you set the routing key for the binding but the exchange is configured as fan-out, Eventuous will produce a warning but will create the binding. Routing key specified when producing messages will be ignored for fan-out exchanges.
+
+### Error handling
+
+Eventuous subscriptions don't throw exceptions when the message handler fails. This behaviour can be changed by changing the `ThrowOnError` subscription option. For RabbitMQ subscriptions, this behaviour is extended by using the requeue feature of the broker. Therefore, by default, if the message handler throws an exception, the message will be put back in the queue and consumed again later. This helps to deal with transient failures in the message handler but also severely impacts message processing order as the retried message is put at the end of the queue.
+
+If you want to ensure that messages are consumed in relative order, you'd need to make sure that message processing is retried inside the handler. Still, if the error doesn't get resolved by retries, the consumer will eventually time out and the message will be put back in the queue. If the message is causing the consumer to fail unconditionally, it is a _poison message_, and it can take put the system into an endless retry loop.
+
+The requeue behaviour is provided by the default failure handler. It's possible to override it by setting the `FailureHandler` property of the subscription options.
+
+## Other messaging frameworks
+
+It's important to understand how Eventuous messaging for RabbitMQ is different compared to other messaging middleware libraries for .NET like MassTransit or NServiceBus.
+
+The most noticeable difference is that both MassTransit and NServiceBus use _message-type-based routing_. It means that by default, they create exchanges for each message type produced by the application. Another default is that the .NET class name is used to compute the exchange name. As a result, any refactoring of the message schema code, like renaming classes, changing namespaces, etc., causes disruption for downstream consumers. As fully qualified class names are also used for deserialization, changes in message class names as well as their namespaces causes issue for downstream consumers and requires coordinated deployments.
+
+Eventuous uses a different approach where the service normally produces messages to its own single exchange which is named after the service. Each subscription gets its own queue and creates a binding to a particular exchange. So, each consumer will get messages with different types, from a particular service. Message type is supplied as a default RabbitMQ `Type` message property. It uses Eventuous [type map](../../persistence/serialisation#type-map) for mapping CLR types to strings, so refactoring namespaces and class name will not affect message routing. In addition, messages are delivered in relative order from one service to another. Certainly, it might affect the system performance as if the subscription queue gets congested, it will keep growing. That can be mitigated by using message priority, which is supported by RabbitMQ.
+
+[1]: https://www.rabbitmq.com/docs/confirms#channel-qos-prefetch
+[2]: https://www.rabbitmq.com/docs/ttl#per-message-ttl-in-publishers
+[3]: https://www.rabbitmq.com/tutorials/tutorial-four-dotnet
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/intro.mdx b/docs/src/content/docs/0.15/intro.mdx
new file mode 100644
index 000000000..a96e317e9
--- /dev/null
+++ b/docs/src/content/docs/0.15/intro.mdx
@@ -0,0 +1,40 @@
+---
+title: "Start here"
+sidebar:
+  order: 1
+---
+
+# Start here
+
+First, why would you use Eventuous instead of rolling out your own library to support Event Sourcing? From our experience, doing that is totally possible, but it's laborious, time-consuming, and prone to failure.
+
+## Do you need it?
+
+Watch this video to learn more about the motivation behind Eventuous:
+
+<iframe width="100%" height="400" src="https://www.youtube.com/embed/qYGKqm7CmFM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+Check out [The Right Way](../prologue/the-right-way) to understand how things go wrong sometimes.
+
+## Next steps
+
+If you are convinced that Eventuous is the right tool for you, here are the next steps:
+- Read the [Prologue](../prologue/introduction) to learn what Eventuous provides
+- Learn more about the basic building blocks:
+  - [Domain model](../domain/aggregate) components
+  - [Persistence](../persistence) for events, and how it differs from the traditional approach
+  - [Application service](../application) components
+  - [Subscriptions](../subscriptions/subs-concept) for event processing (like [read models](../read-models/rm-concept))
+- Check sample applications to see how Eventuous is used in practice:
+  - [EventStoreDB](https://github.com/eventuous/dotnet-sample) sample
+  - [PostgreSQL](https://github.com/eventuous/dotnet-sample-postgres) sample
+
+## Community
+
+Eventuous is actively maintained. You can report issues in the [GitHub repository](https://github.com/eventuous/eventuous/issues).
+
+Ensure you follow the [Code of Conduct](https://github.com/Eventuous/eventuous/blob/da47a6918626b26428063be0e115ff75c539602b/CODE_OF_CONDUCT.md) when interacting with the community. When contributing, please follow the [Contributing Guidelines](https://github.com/Eventuous/eventuous/blob/da47a6918626b26428063be0e115ff75c539602b/CONTRIBUTING.md).
+
+Eventuous is open source and licensed under the Apache 2.0 licence.
+
+Support the project by providing [sponsorships](https://github.com/sponsors/Eventuous). Eventuous has sponsor plans for both individuals and companies. You can get paid support for your projects, or just show your appreciation for the project.
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/persistence/aggregate-store.mdx b/docs/src/content/docs/0.15/persistence/aggregate-store.mdx
new file mode 100644
index 000000000..25676121c
--- /dev/null
+++ b/docs/src/content/docs/0.15/persistence/aggregate-store.mdx
@@ -0,0 +1,139 @@
+---
+title: "Aggregate store"
+description: "How aggregates are stored in an event store"
+---
+
+:::note[Deprecation notice]
+Since version **0.15**, Eventuous doesn't use _Aggregate store_ internally. All persistence operations in command services are using [Event store](../event-store). The following elements are marked obsolete:
+
+- `IAggregateStore` interface
+- `AggregateStore` class
+- `AggregateStore<TArchive>` class
+- Dependency injection registration methods for Aggregate store
+
+Look in the previous version documentation to learn about `IAggregateStore` and its usage.
+:::
+
+:::note
+Eventuous does not have a concept of Repository. Find out why [on this page](..).
+:::
+
+Eventuous provides a number of extensions for `IEventReader` and `IEventWriter` interfaces for aggregate persistence.
+
+## Storing aggregates
+
+Storing an aggregate instance implies appending new events from the list of changes to the [aggregate stream](../aggregate-stream). Functions that allow that are listed below. All those are extensions to `IEventWriter` interface.
+
+### Using stream name
+
+This function requires a pre-calculated stream name to be provided, so it doesn't use any convention for resolving stream names. It uses the provided stream name as-is.
+
+```csharp
+Task<AppendEventsResult> IEventWriter.StoreAggregate<TAggregate, TState>(
+    StreamName        streamName,
+    TAggregate        aggregate,
+    AmendEvent?       amendEvent        = null,
+    CancellationToken cancellationToken = default
+)
+```
+
+| Parameter           | Type                             | Description                                             |
+|---------------------|----------------------------------|---------------------------------------------------------|
+| `streamName`        | `StreamName`                     | Aggregate stream name                                   |
+| `aggregate`         | `TAggregate<TState>`             | Aggregate instance                                      |
+| `amendEvent`        | `Func<StreamEvent, StreamEvent>` | Function that allows adding things like custom metadata |
+| `cancellationToken` | `CancellationToken`              | Cancellation token                                      |
+
+### Using explicit aggregate id
+
+This function uses the stream name map to convert the provided aggregate identity to a stream name. If the stream name map is not supplied, it will use the default, convention-based calculation (`TypeName-Id`).
+
+```csharp
+Task<AppendEventsResult> IEventWriter.StoreAggregate<TAggregate, TState, TId>(
+    TAggregate        aggregate,
+    TId               id,
+    StreamNameMap?    streamNameMap     = null,
+    AmendEvent?       amendEvent        = null,
+    CancellationToken cancellationToken = default
+)
+```
+
+| Parameter           | Type                             | Description                                                                        |
+|---------------------|----------------------------------|------------------------------------------------------------------------------------|
+| `aggregate`         | `TAggregate<TState>`             | Aggregate instance                                                                 |
+| `id`                | `TId`                            | Aggregate identity                                                                 |
+| `streamNameMap`     | `StreamNameMap`                  | [Map](../aggregate-stream#aggregate-streams) between identities and stream names |
+| `amendEvent`        | `Func<StreamEvent, StreamEvent>` | Function that allows adding things like custom metadata                            |
+| `cancellationToken` | `CancellationToken`              | Cancellation token                                                                 |
+
+### Using aggregate identity from state
+
+This function supports storing aggregates with identity-aware state (`State<TId>`) and uses the aggregate `State.Id` property combined with the stream name map to resolve the stream name. If the stream name map is not supplied, it will use convention-based stream name calculation.
+
+```csharp
+Task<AppendEventsResult> IEventWriter.StoreAggregate<TAggregate, TState, TId>(
+    TAggregate        aggregate,
+    StreamNameMap?    streamNameMap     = null,
+    AmendEvent?       amendEvent        = null,
+    CancellationToken cancellationToken = default
+)
+```
+
+| Parameter           | Type                             | Description                                                                        |
+|---------------------|----------------------------------|------------------------------------------------------------------------------------|
+| `aggregate`         | `TAggregate<TState, TId>`        | Aggregate instance                                                                 |
+| `streamNameMap`     | `StreamNameMap`                  | [Map](../aggregate-stream#aggregate-streams) between identities and stream names |
+| `amendEvent`        | `Func<StreamEvent, StreamEvent>` | Function that allows adding things like custom metadata                            |
+| `cancellationToken` | `CancellationToken`              | Cancellation token                                                                 |
+
+## Loading aggregates
+
+Several extensions for `IEventReader` interface allow loading aggregates from an event store.
+
+### Using stream name
+
+This function requires a pre-calculated stream name to be provided, so it doesn't use any convention for resolving stream names. It uses the provided stream name as-is.
+
+```csharp
+Task<TAggregate> LoadAggregate<TAggregate, TState>(
+    StreamName                streamName,
+    bool                      failIfNotFound    = true,
+    AggregateFactoryRegistry? factoryRegistry   = null,
+    CancellationToken         cancellationToken = default
+)
+```
+
+| Parameter           | Type                       | Description                                                                                                                                                     |
+|---------------------|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `streamName`        | `StreamName`               | Aggregate stream name                                                                                                                                           |
+| `failIfNotFound`    | `bool`                     | When set to `true`, the function will throw an `AggregateNotFound` exception if the stream cannot be found. Otherwise, it will return a new aggregate instance. |
+| `factoryRegistry`   | `AggregateFactoryRegistry` | Optional aggregate factory registry, which is used to create new aggregate instances. If not supplied, the default registry is used.                            |
+| `cancellationToken` | `CancellationToken`        | Cancellation token                                                                                                                                              |
+
+### Using aggregate id
+
+This function uses the stream name map to convert the provided aggregate identity to a stream name. If the stream name map is not supplied, it will use the default, convention-based calculation (`TypeName-Id`).
+
+```csharp
+Task<TAggregate> IEventWriter.LoadAggregate<TAggregate, TState, TId>(
+    TId                       aggregateId,
+    StreamNameMap?            streamNameMap     = null,
+    bool                      failIfNotFound    = true,
+    AggregateFactoryRegistry? factoryRegistry   = null,
+    CancellationToken         cancellationToken = default
+)
+```
+
+| Parameter           | Type                       | Description                                                                                                                                                     |
+|---------------------|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `id`                | `TId`                      | Aggregate identity                                                                                                                                              |
+| `streamNameMap`     | `StreamNameMap`            | [Map](../aggregate-stream#aggregate-streams) between identities and stream names                                                                              |
+| `failIfNotFound`    | `bool`                     | When set to `true`, the function will throw an `AggregateNotFound` exception if the stream cannot be found. Otherwise, it will return a new aggregate instance. |
+| `factoryRegistry`   | `AggregateFactoryRegistry` | Optional aggregate factory registry, which is used to create new aggregate instances. If not supplied, the default registry is used.                            |
+| `cancellationToken` | `CancellationToken`        | Cancellation token                                                                                                                                              |
+
+## Multi-tier store
+
+:::note[Deprecation notice]
+Since version **0.15**, aggregate store with archive is superseded by [tiered event store](../event-store#event-store-with-archive).
+:::
diff --git a/docs/src/content/docs/0.15/persistence/aggregate-stream.md b/docs/src/content/docs/0.15/persistence/aggregate-stream.md
new file mode 100644
index 000000000..d88e94ca3
--- /dev/null
+++ b/docs/src/content/docs/0.15/persistence/aggregate-stream.md
@@ -0,0 +1,174 @@
+---
+title: "Entity stream"
+description: "State as a stream of events"
+sidebar:
+  order: 1
+---
+
+## Concept
+
+So far, we figured out that an [Aggregate](../../domain/aggregate) is the transaction and consistency boundary within the domain model.
+
+The [aggregate store](../aggregate-store) (application-level abstraction) uses an [event store](../event-store) (infrastructure) to store events in streams. Each aggregate instance has its own stream, so the event store needs to be capable to read and write events from/to the correct stream.
+
+When appending events to a stream, the append operation for a single stream must be transactional to ensure that the stream is consistent. Eventuous handles commands using the [command service](../../application/app-service), and one command handler is the unit of work. All the events generated by the aggregate instance during the unit of work are appended to the stream as the final step in the command handling process.
+
+## Stream name
+
+As a stream is a boundary for a single entity state, its name must be unique per entity. Therefore, the stream name usually consists of an identifiable class name associated with the entity state (aggregate type name, state type name) without suffixes like `Aggregate`, `Entity` or `State`, combined with the entity id. Eventuous uses a convention to separate those two with a dash.
+
+For example, for an entity called `Booking` where it might be represented as a `Booking` aggregate or `BookingState` state record, the stream name will start with `Booking-` followed by the entity id. So, a booking with id `123` will have a stream name `Booking-123`.
+
+### Aggregate streams
+
+For aggregates, Eventuous uses the `AggregateType.Name` combined with the aggregate id as the stream name. When using an aggregate-based command service, each command handler defines how the aggregate id is resolved from a command:
+
+```csharp
+On<ImportBooking>()
+    .InState(ExpectedState.New)
+    .GetId(cmd => new(cmd.BookingId))
+    .Act((booking, cmd) => booking.Import(cmd.RoomId, new(cmd.CheckIn, cmd.CheckOut), new(cmd.Price)));
+```
+
+In the example above, if the `ImportBooking.BookingId` property has a value `123`, the service will construct a `BookingId` instance with value `123`. Then, the service will use `StreamName.For<Booking>(id)` where `id` is of type `BookingId` to determine the stream name. Following the example, it will use `Booking-123` as the stream name, where `Booking` is the aggregate type name, and `123` is the aggregate identity value as string.
+
+However, you might want to have more fine-grained control over the stream name. For example, you might want to include the tenant id in the stream name. It's possible to override the default convention by configuring the stream name mapping. The stream map contains a mapping between the aggregate identity type (derived from `Id`) and the stream name generation function. Therefore, any additional property of the aggregate identity type can be used to generate the stream name.
+
+For example, the following code registers a stream name mapping for the `Booking` aggregate:
+
+```csharp title="BookingId.cs"
+public record BookingId(string Value, string Tenant) : Id(Value);
+```
+
+Create a `StreamNameMap` and register in the container:
+
+```csharp title="Program.cs"
+var streamNameMap = new StreamNameMap();
+streamNameMap.Register<BookingId>(
+    id => new StreamName($"Booking-{id.Tenant}:{id.Value}") 
+);
+builder.Services.AddSingleton(streamNameMap);
+builder.Services.AddCommandService<BookingService, BookingState>();
+```
+
+Then, use the registered `StreamNameMap` in the `CommandService`:
+
+```csharp title="BookingService.cs"
+// Aggregate service
+public class BookingService : CommandService<Booking, BookingState, BookingId> {
+    public BookingService(IEventStore store, StreamNameMap streamNameMap)
+        : base(store, streamNameMap: streamNameMap) {
+        // command handlers registered here
+    }
+}
+```
+
+### State streams
+
+State streams and aggregate streams are essentially the same. Aggregates don't persist anything else than their state. The difference from the API perspective is in how stream names are resolved by command services.
+
+While aggregate-based services calculate stream names using the aggregate type name and aggregate identity, functional services expect you to specify a function to retrieve the stream name from a command when you defined the command handler. 
+
+Let's have a look at the following command handler definition:
+
+```csharp
+// Constructor of BookingService : CommandService<BookingState>
+On<BookRoom>()
+    .InState(ExpectedState.New)
+    .GetStream(cmd => GetStream(cmd.BookingId))
+    .Act(BookRoom);
+```
+
+Here, the command service is instructed to use the default way to resolve the stream name from a command. It uses the `GetStream` function available in the command service base class, which calls `StreamName.ForState<TState>` function. By convention, it will take the `TState` type name, remove `State` word from it if it's there, and append a dash followed the entity id to the string. So, if the `BookRoom.Id` property has a value `123`, the stream name would be resolved as `Booking-123`. 
+
+## Reversing stream name to identity
+
+As you don't need to include the entity or aggregate id to the events, you might be wondering how to get the identity in, for example, downstream event handlers like read model projections. For that purpose, you'd need to resolve the identity from the stream name.
+
+### Convention-based
+
+There are several options available to determine the entity or aggregate id, which then can be used as a document id or primary key for projected models, from stream names.
+
+First, the `StreamName` struct provides the `GetId()` function that returns the convention-based identity. It takes part of the stream name string following the dash and returns it as a string. For example, if the stream name is `Booking-123`, `GetId()` will return `123`.
+
+For example, a projecting handler for MongoDB uses it like this:
+
+```csharp
+On<BookingImported>(
+    b => b
+        .InsertOne
+        .Document(
+            (stream, e) => new(stream.GetId()) {
+                RoomId       = e.RoomId,
+                CheckInDate  = e.CheckIn,
+                CheckOutDate = e.CheckOut,
+                BookingPrice = e.Price,
+                Outstanding  = e.Price
+            }
+        )
+);
+```
+
+MongoDB projections also provide a `DefaultId()` helper that also uses the convention:
+
+```csharp
+On<BookingPaymentRegistered>(
+    b => b
+        .UpdateOne
+        .DefaultId()
+        .Update((evt, update) => update.Set(x => x.PaidAmount, evt.AmountPaid))
+);
+```
+
+### Custom stream names
+
+Convention-based approach won't work if you use custom stream names. In that case, you'd need to write code to calculate the identity value from stream names.
+
+For example, your projections can retrieve the `Id` and `TenantId` from the `StreamName` in the `IMessageConsumeContext<T>`:
+
+```csharp title="BookingStateProjection.cs"
+static UpdateDefinition<BookingDocument> HandleRoomBooked(
+    IMessageConsumeContext<V1.RoomBooked> ctx, 
+    UpdateDefinitionBuilder<BookingDocument> update
+) {
+    var evt = ctx.Message;
+
+    // Get Id and TenantId
+    var (id, tenantId) = ctx.Stream.ExtractMultiTenantIds();
+
+    return update
+        .SetOnInsert(x => x.Id, id) 
+        .SetOnInsert(x => x.TenantId, tenantId)
+        .Set(x => x.GuestId, evt.GuestId)
+        .Set(x => x.RoomId, evt.RoomId)
+        .Set(x => x.CheckInDate, evt.CheckInDate)
+        .Set(x => x.CheckOutDate, evt.CheckOutDate)
+        .Set(x => x.BookingPrice, evt.BookingPrice)
+        .Set(x => x.Outstanding, evt.OutstandingAmount);
+}
+```
+
+The snippet above uses the following extension method to extract the `Id` and `TenantId` from the `StreamName`:
+
+```csharp title="StreamNameExtensions.cs"
+/// <summary>
+/// Split the StreamName into multiple parts for multi tenant stream id.
+/// </summary>
+/// <param name="stream">The streamname</param>
+/// <param name="separator">The seperator for splitting. Default is ':'.</param>
+/// <returns>A tuple with TenantId and Id property.</returns>
+/// <exception cref="InvalidStreamName">When stream id can't be split in 2 sections.</exception>
+public static (string TenantId, string Id) ExtractMultiTenantIds(
+    this StreamName stream, 
+    char separator = ':'
+) {
+    var streamId = stream.GetId(); // Returns "tenant:id" from "Booking-tenant:id"
+    var parts = streamId.Split(separator);
+
+    if (parts.Length != 2) {
+        throw new InvalidStreamName(streamId);
+    }
+
+    return (parts[0], parts[1]);
+}
+```
diff --git a/docs/src/content/docs/persistence/event-store.mdx b/docs/src/content/docs/0.15/persistence/event-store.mdx
similarity index 97%
rename from docs/src/content/docs/persistence/event-store.mdx
rename to docs/src/content/docs/0.15/persistence/event-store.mdx
index bbf312b75..67e93fa7a 100644
--- a/docs/src/content/docs/persistence/event-store.mdx
+++ b/docs/src/content/docs/0.15/persistence/event-store.mdx
@@ -5,7 +5,11 @@ sidebar:
   order: 2
 ---
 
-import ThemedImage from '../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import replication from './images/replication.png';
+import replicationDark from './images/replication-dark.png';
+import reading from './images/reading.png';
+import readingDark from './images/reading-dark.png';
 
 In order to isolate the core library from a particular way of storing events, Eventuous uses the `IEventStore` abstraction.
 
@@ -108,8 +112,8 @@ When the connector is running, it will replicate all events from one store to th
 
 <ThemedImage
     alt="Replication process"
-    lightSrc="./images/replication.png"
-    darkSrc="./images/replication-dark.png"
+    lightSrc={replication}
+    darkSrc={replicationDark}
 />
 
 You'd need to have the connector [up and running](https://connect.eventuous.dev/docs/deployment/) before you can use Elasticsearch as the cold store in Eventuous-based application.
@@ -154,8 +158,8 @@ The process of reading events from the tiered store looks like this:
 
 <ThemedImage
     alt="Reading from two stores"
-    lightSrc="./images/reading.png"
-    darkSrc="./images/reading-dark.png"
+    lightSrc={reading}
+    darkSrc={readingDark}
 />
 
 Here's the reading process described step-by-step:
diff --git a/docs/src/content/docs/0.15/persistence/images/reading-dark.png b/docs/src/content/docs/0.15/persistence/images/reading-dark.png
new file mode 100644
index 000000000..c6f850ceb
Binary files /dev/null and b/docs/src/content/docs/0.15/persistence/images/reading-dark.png differ
diff --git a/docs/src/content/docs/0.15/persistence/images/reading.png b/docs/src/content/docs/0.15/persistence/images/reading.png
new file mode 100644
index 000000000..dfda40fd2
Binary files /dev/null and b/docs/src/content/docs/0.15/persistence/images/reading.png differ
diff --git a/docs/src/content/docs/0.15/persistence/images/replication-dark.png b/docs/src/content/docs/0.15/persistence/images/replication-dark.png
new file mode 100644
index 000000000..19f6afc54
Binary files /dev/null and b/docs/src/content/docs/0.15/persistence/images/replication-dark.png differ
diff --git a/docs/src/content/docs/0.15/persistence/images/replication.png b/docs/src/content/docs/0.15/persistence/images/replication.png
new file mode 100644
index 000000000..bc5e84a22
Binary files /dev/null and b/docs/src/content/docs/0.15/persistence/images/replication.png differ
diff --git a/docs/src/content/docs/0.15/persistence/serialisation.md b/docs/src/content/docs/0.15/persistence/serialisation.md
new file mode 100644
index 000000000..069a5a6ca
--- /dev/null
+++ b/docs/src/content/docs/0.15/persistence/serialisation.md
@@ -0,0 +1,127 @@
+---
+title: "Serialization"
+description: "How events are serialized and deserialized"
+---
+
+As described on the [Domain events](../../domain/domain-events) page, events must be (de)serializable. Eventuous doesn't care about the serialization format, but requires you to provide a serializer instance, which implements the `IEventSerializer` interface.
+
+The serializer interface is simple:
+
+```csharp title="IEventSerializer.cs"
+public interface IEventSerializer {
+    DeserializationResult DeserializeEvent(ReadOnlySpan<byte> data, string eventType, string contentType);
+
+    SerializationResult SerializeEvent(object evt);
+}
+```
+
+The serialization result contains not only the serialized object as bytes, but also the event type as string (see below), and the content type:
+
+```csharp
+public record SerializationResult(string EventType, string ContentType, byte[] Payload);
+```
+
+### Type map
+
+For deserialization, the serializer will get the binary payload and the event type as string. Event store is unaware of your event types, it just stores the payload in a binary format to the database, along with the event type as string. It is up to you how your strong event types map to the event type string.
+
+:::caution
+We do not advise using fully-qualified type names as event types. It will block your ability to refactor the domain model code.
+:::
+
+Therefore, we need to have a way to map strong types of the events to strings, which are used to identify those types in the database and for serialization. For that purpose, Eventuous uses the `TypeMap`. It is a singleton, which is available globally. When you add new events to your domain model, remember to also add a mapping for those events. The mapping is static, so you can implement it anywhere in the application. The only requirement is that the mapping code must execute when the application starts.
+
+For example, if you have a place where domain events are defined, you can put the mapping code there, as a static member:
+
+```csharp title="BookingEvents.cs"
+static class BookingEvents {
+    // events are defined here
+
+    public static void MapBookingEvents() {
+        TypeMap.AddType<RoomBooked>("RoomBooked");
+        TypeMap.AddType<BookingPaid>("BookingPaid");
+        TypeMap.AddType<BookingCancelled>("BookingCancelled");
+        TypeMap.AddType<BookingImported>("BookingImported");
+    }
+}
+```
+
+Then, you can call this code in your bootstrap code:
+
+```csharp title="Program.cs"
+BookingEvents.MapBookingEvents();
+```
+
+### Auto-registration of types
+
+For convenience purposes, you can avoid manual mapping between type names and types by using the `EventType` attribute.
+
+Annotate your events with it like this:
+
+```csharp
+[EventType("V1.FullyPaid")]
+public record BookingFullyPaid(string BookingId, DateTimeOffset FullyPaidAt);
+```
+
+Then, use the registration code in the bootstrap code:
+
+```csharp
+TypeMap.RegisterKnownEventTypes();
+```
+
+The registration won't work if event classes are defined in another assembly, which hasn't been loaded yet. You can work around this limitation by specifying one or more assemblies explicitly:
+
+```csharp
+TypeMap.RegisterKnownEventTypes(typeof(BookingFullyPaid).Assembly);
+```
+
+If you use the .NET version that supports module initializers, you can register event types in the module. For example, if the domain event classes are located in a separate project, add the file `DomainModule.cs` to that project with the following code:
+
+```csharp title="DomainModule.cs"
+using System.Diagnostics.CodeAnalysis;
+using System.Runtime.CompilerServices;
+using Eventuous;
+
+namespace Bookings.Domain; 
+
+static class DomainModule {
+    [ModuleInitializer]
+    [SuppressMessage("Usage", "CA2255", MessageId = "The \'ModuleInitializer\' attribute should not be used in libraries")]
+    internal static void InitializeDomainModule() => TypeMap.RegisterKnownEventTypes();
+}
+```
+
+Then, you won't need to call the `TypeMap` registration in the application code at all.
+
+### Default serializer
+
+Eventuous provides a default serializer implementation, which uses `System.Text.Json`. You just need to register it in the `Startup` to make it available for the infrastructure components, like [aggregate store](../aggregate-store) and [subscriptions](../../subscriptions/subs-concept).
+
+Normally, you don't need to register or provide the serializer instance to any of the Eventuous classes that perform serialization and deserialization work. It's because they will use the default serializer instance instead.
+
+However, you can register the default serializer with different options, or a custom serializer instead:
+
+```csharp title="Program.cs"
+builder.Services.AddSingleton<IEventSerializer>(
+    new DefaultEventSerializer(
+        new JsonSerializerOptions(JsonSerializerDefaults.Default)
+    )
+);
+```
+
+You might want to avoid registering the serializer and override the one that Eventuous uses as the default instance:
+
+```csharp title="Program.cs"
+var defaultSerializer = new DefaultEventSerializer(
+    new JsonSerializerOptions(JsonSerializerDefaults.Default)
+);
+DefaultEventSerializer.SetDefaultSerializer(serializer);
+```
+
+### Metadata serializer
+
+In many cases you might want to store event metadata in addition to the event payload. Normally, you'd use the same way to serialize both the event payload and its metadata, but it's not always the case. For example, you might store your events in Protobuf, but keep metadata as JSON.
+
+Eventuous only uses the metadata serializer when the event store implementation, or a producer can store metadata as a byte array. For example, EventStoreDB supports that, but Google PubSub doesn't. Therefore, the event store and producer that use EventStoreDB will use the metadata serializer, but the Google PubSub producer will add metadata to events as headers, and won't use the metadata serializer.
+
+For the metadata serializer the same principles apply as for the event serializer. Eventuous has a separate interface `IMetadataSerializer`, which has a default instance created on startup by implicitly. You can register a custom metadata serializer as a singleton or override the default one by calling `DefaultMetadataSerializer.SetDefaultSerializer` function. 
diff --git a/docs/src/content/docs/0.15/producers/implementation.md b/docs/src/content/docs/0.15/producers/implementation.md
new file mode 100644
index 000000000..94cfbad5b
--- /dev/null
+++ b/docs/src/content/docs/0.15/producers/implementation.md
@@ -0,0 +1,70 @@
+---
+title: "Implementation"
+sidebar:
+  order: 100
+description: "How producers are implemented"
+---
+
+## Abstraction
+
+Eventuous has two types of producers: with or without produce options. The producer without produce options is a simple producer that does not support any options, and it normally produces messages as-is. The producer with produce options can have more fine-grained control on how messages are produced. Produce options are provided per message batch.
+
+The base interface for a producer is called `IProducer<TProduceOptions>` and its only method is `Produce`.
+
+```csharp
+Task Produce(
+    StreamName                   stream,
+    IEnumerable<ProducedMessage> messages,
+    TProduceOptions?             options,
+    CancellationToken            cancellationToken = default
+);
+```
+
+Some producers require lifecycle management so they can execute some operations on startup and on shut down. Those producers implement the `IHostedProducer` interface has a property named `Ready`, which indicates the producer's readiness. This property is also important for gateways to determine if the producer is prepared to produce messages.
+
+## Base producer
+
+There is an abstract base class for producers called `BaseProducer`.
+
+The purpose for the base class is to enable tracing for produced messages. All producers implemented in Eventuous use the base producer class. For the purpose of tracing, the base producer class accepts `ProducerTracingOptions` as a parameter.
+
+```csharp
+public record ProducerTracingOptions {
+    public string? MessagingSystem  { get; init; }
+    public string? DestinationKind  { get; init; }
+    public string? ProduceOperation { get; init; }
+}
+```
+
+These options are used to set the producer trace tags that are specific for the infrastructure. For example, the messaging system tag for `RabbitMqProducer` is `rabbitmq`.
+
+Both base classes implement the `Produce` method. It is only used to enable tracing. The actual producing is done by the `ProduceMessages` abstract method. When implementing a new producer using the base class, you'd only need to implement the `ProduceMessages` method.
+
+You can see that for producing a message, the producer gets a collection of `ProducedMessage` record. It looks like this:
+
+```csharp
+public record ProducedMessage {
+    public object               Message     { get; }
+    public Metadata?            Metadata    { get; init; }
+    public AcknowledgeProduce?  OnAck       { get; init; }
+    public ReportFailedProduce? OnNack      { get; init; }
+}
+```
+
+The `Message` property represents the actual message payload. Producers typically use an `IEventSerializer` instance to serialize the message payload. However, in certain situations, producers may need to comply with their supporting infrastructure and use a different method for serializing the message payload. In such cases, the `MessageType property can be included in the produced message body or header, allowing for proper deserialization by subscribers.
+
+As base producer is responsible for tracing, it creates the produce span and set some tags for it. Learn more on the [Diagnostics](../../diagnostics/traces) page. The base producer is unaware of the message type, and if the producer implementation wants to set the message type as a span tag, it should call the `SetActivityMessageType` method of the base class. All bundled producers do that except Elasticsearch producer.
+
+## Registration
+
+Eventuous provides several extensions to the `IServiceCollection` interface to register producers. You can provide a pre-made producer instance, a function to resolve the producer from the `IServiceProvider`, or simply the producer type if its dependencies can be resolved automatically.
+
+For instance, if you have already registered the `EventStoreClient` instance, you can register the `EventStoreProducer` as follows:
+
+```csharp title="Program.cs"
+builder.Services.AddProducer<EventStoreProducer>();
+```
+
+If a producer requires some work to be done before it is ready, it should implement the `IHostedProducer` interface, allowing it to perform necessary startup tasks in its `StartAsync` method. When using any of the `AddProducer` extensions, if the producer implements `IHostedProducer`, it will be registered as such.
+
+Keep in mind that producers are typically registered as singletons. If you require multiple producer instances for the same infrastructure within your application (like two RabbitMQ producers for different RabbitMQ instances), you must provide them as direct dependencies rather than registering them. It's uncommon to need multiple producer instances, unless you are utilizing gateways. The various `AddProducer` overloads register the specified producer as both `IProducer` and its implementing service class. For example, `AddProducer<RabbitMqProducer>` will register both `IProducer` and `RabbitMqProducer`. Gateway registration extensions are capable of utilizing individual producer instances as dependencies.
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/producers/index.mdx b/docs/src/content/docs/0.15/producers/index.mdx
new file mode 100644
index 000000000..8241bb0a0
--- /dev/null
+++ b/docs/src/content/docs/0.15/producers/index.mdx
@@ -0,0 +1,14 @@
+---
+title: "Producers"
+description: "Message producers"
+sidebar:
+  order: 700
+---
+
+Producers, along with [Subscriptions](../subscriptions/subs-concept), are the foundation of the Eventuous' messaging system.
+
+## Concept
+
+Although an [event store](../persistence/event-store) produces events too, it is normally used via the [Aggregate store](../persistence/aggregate-store). Sometimes, you just need to produce arbitrary messages, which aren't necessarily events. For example, you can also produce commands. Still, the main purpose of a producer is to put events to an event database or a broker, so they can be consumed by a subscription.
+
+Within Eventuous, the main purpose of producers is to support [gateways](../gateway), and, through gateways, enable creation of [connectors](https://connector.eventuous.dev).
diff --git a/docs/src/content/docs/0.15/producers/providers.md b/docs/src/content/docs/0.15/producers/providers.md
new file mode 100644
index 000000000..f4a5f8502
--- /dev/null
+++ b/docs/src/content/docs/0.15/producers/providers.md
@@ -0,0 +1,12 @@
+---
+title: "Available producers"
+description: "List of producers available in Eventuous"
+---
+
+Eventuous supports the following producers:
+
+- [EventStoreDB](../../infra/esdb#producer)
+- [Apache Kafka](../../infra/kafka#producer)
+- [RabbitMQ](../../infra/rabbitmq#producer)
+- [Google PubSub](../../infra/pubsub#producer)
+- [Elasticsearch](../../infra/elastic)
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/prologue/images/flaming-bus.jpg b/docs/src/content/docs/0.15/prologue/images/flaming-bus.jpg
new file mode 100644
index 000000000..219596e6a
Binary files /dev/null and b/docs/src/content/docs/0.15/prologue/images/flaming-bus.jpg differ
diff --git a/docs/src/content/docs/0.15/prologue/images/the-right-way-dark.png b/docs/src/content/docs/0.15/prologue/images/the-right-way-dark.png
new file mode 100644
index 000000000..b3f4ae193
Binary files /dev/null and b/docs/src/content/docs/0.15/prologue/images/the-right-way-dark.png differ
diff --git a/docs/src/content/docs/0.15/prologue/images/the-right-way.png b/docs/src/content/docs/0.15/prologue/images/the-right-way.png
new file mode 100644
index 000000000..2c217b70d
Binary files /dev/null and b/docs/src/content/docs/0.15/prologue/images/the-right-way.png differ
diff --git a/docs/src/content/docs/0.15/prologue/introduction.md b/docs/src/content/docs/0.15/prologue/introduction.md
new file mode 100644
index 000000000..55336b333
--- /dev/null
+++ b/docs/src/content/docs/0.15/prologue/introduction.md
@@ -0,0 +1,64 @@
+---
+title: "Introduction"
+description: >
+    What is Eventuous and why you want to use it for implementing an event-sourced system with .NET or .NET Core?
+sidebar:
+  order: 1
+---
+
+## What is Eventuous?
+
+Eventuous is a (relatively) lightweight library, which allows building production-grade applications using the [Event Sourcing](https://www.kurrent.io/resources/eventsourcing/what-is-event-sourcing) pattern.
+
+The base library has a set of abstractions, following Domain-Driven Design tactical patterns, like `Aggregate`.
+
+Additional components include:
+- [Aggregate persistence](../../persistence) using [EventStoreDB](https://eventstore.com), PostgreSQL, and Microsoft SQL Server
+- [Real-time subscriptions](../../subscriptions/subs-concept) for EventStoreDB, PostgreSQL, Microsoft SQL Server, RabbitMQ, and Google PubSub
+- [Command services](../../application) and HTTP-based commands
+- Extensive observability, including Open Telemetry support
+- Integration with ASP.NET Core dependency injection, logging, and Web API
+- [Producers](../../producers) for EventStoreDB, RabbitMQ, Google PubSub, and Apache Kafka
+- [Read model](../../read-models/rm-concept) projections for MongoDB
+- [Gateway](../../gateway) for producing events to other services (Event-Driven Architecture support)
+
+:::note
+Eventuous is under active development and doesn't follow semantic versioning. We introduce changes often, according to immediate needs of its production users. The API hasn't reached a stable state and can change at any time. A patch version update would normally not change the API, but the minor version cloud.
+:::
+
+### Packages
+
+You can find all the NuGet packages by visiting the [Eventuous profile](https://www.nuget.org/profiles/Eventuous/).
+
+| Package                               | What's it for                                                                                              |
+|---------------------------------------|------------------------------------------------------------------------------------------------------------|
+| `Eventuous`                           | The umbrella package that includes the most used components                                                |
+| `Eventuous.Domain`                    | Library that includes the [domain model](../../domain/aggregate) abstractions like aggregates                           |
+| `Eventuous.Persistence`               | The base library for [persistence](../../persistence), including event store and aggregate store abstractions |
+| `Eventuous.Application`               | [Command services](../../application) base library, including diagnostics and DI support                      |
+| `Eventuous.Subscriptions`             | [Subscriptions](../../subscriptions/subs-concept) base library, including diagnostics and DI support                       |
+| `Eventuous.Subscriptions.Polly`       | Support for retries in event handlers using [Polly](http://www.thepollyproject.org/)                       |
+| `Eventuous.Producers`                 | [Producers](../../producers) base library, including diagnostics and DI support                               |
+| `Eventuous.Diagnostics`               | Diagnostics base library                                                                                   |
+| `Eventuous.Diagnostics.OpenTelemetry` | Diagnostics integration with [OpenTelemetry](https://opentelemetry.io/)                                    |
+| `Eventuous.Diagnostics.Logging`       | Eventuous internal logs adapter for ASP.NET Core logging                                                   |
+| `Eventuous.Gateway`                   | Eventuous [gateway](../../gateway) for connecting subscriptions with producers                                |
+| `Eventuous.EventStore`                | Support for [EventStoreDB](../../infra/esdb) (event store, subscriptions, producers)                          |
+| `Eventuous.Postgresql`                | Support for [PostgreSQL](../../infra/postgres) (event store, subscriptions, producers)                        |
+| `Eventuous.SqlServer`                 | Support for [Microsoft SQL Server](../../infra/mssql) (event store, subscriptions, producers)                 |
+| `Eventuous.RabbitMq`                  | Support for RabbitMQ (subscriptions, producers)                                                            |
+| `Eventuous.GooglePubSub`              | Support for Google PubSub (subscriptions, producers)                                                       |
+| `Eventuous.Kafka`                     | Support for Apache Kafka (producers)                                                                       |
+| `Eventuous.ElasticSearch`             | Support for Elasticsearch (producers, event store for archive purposes)                                    |
+| `Eventuous.Projections.MongoDB`       | Projections support for [MongoDB](https://www.mongodb.com/)                                                |
+| `Eventuous.AspNetCore`                | DI extensions for app services, aggregate factory, etc.                                                    |
+| `Eventuous.AspNetCore.Web`            | [HTTP API automation](../../application/command-api) for app services                                         |
+
+Normally, for the domain model project, you would only need to reference `Eventuous.Domain` package.
+
+## Go further - WIP
+
+Read about [the right way](../the-right-way) to understand how Eventuous embraces the original idea of Event Sourcing.
+
+You can have a look at the sample project in a [separate repository](https://github.com/Eventuous/dotnet-sample).
+
diff --git a/docs/src/content/docs/0.15/prologue/quick-start.md b/docs/src/content/docs/0.15/prologue/quick-start.md
new file mode 100644
index 000000000..7c6c40617
--- /dev/null
+++ b/docs/src/content/docs/0.15/prologue/quick-start.md
@@ -0,0 +1,12 @@
+---
+title: "Quick start"
+description: "Sample application"
+sidebar:
+  order: 2
+---
+
+You can find a bookings sample application here:
+- [.NET EventStoreDB write => MongoDB read](https://github.com/Eventuous/eventuous/tree/dev/samples/esdb)
+- [.NET PostgreSQL write => MongoDB read](https://github.com/Eventuous/eventuous/tree/dev/samples/postgres)
+
+Samples are being updated with the latest features and improvements.
diff --git a/docs/src/content/docs/0.15/prologue/the-right-way.mdx b/docs/src/content/docs/0.15/prologue/the-right-way.mdx
new file mode 100644
index 000000000..2cdb295a1
--- /dev/null
+++ b/docs/src/content/docs/0.15/prologue/the-right-way.mdx
@@ -0,0 +1,81 @@
+---
+title: "The Right Way"
+description: >
+    Event Sourcing done right, as it meant to be. Don't get caught up in the misconception that Event Sourcing is the same thing
+    as Event-Driven Architecture.
+---
+import ThemedImage from '@components/ThemedImage.astro';
+import theRightWay from './images/the-right-way.png';
+import theRightWayDark from './images/the-right-way-dark.png';
+
+If you've ever searched for a diagram that explains Event Sourcing, you may have found many images, but most of them are confusing or simply incorrect. Despite claims that Event Sourcing is difficult, many people who have this opinion have never actually tried it or made mistakes during implementation.
+
+Eventuous does not claim to be the ultimate authority on the subject. In fact, the library's code is based on previous successful implementations in production and reflects a specific approach to Event Sourcing.
+
+However, in response to the demand for guidance on doing Event Sourcing correctly, we have a solution for you here.
+
+## How Eventuous does it
+
+The core of the application is the domain model, which contains essential business functionality that is encapsulated in domain objects. This is the only place where business logic is implemented.
+
+The command services receive commands from the external environment and forward them to the domain model. They are responsible for validating commands, calling domain object functions, and managing persistence.
+
+The newly generated events are stored in the event store, which requires a database capable of pushing new events in real-time to subscribers.
+
+The event store pushes the stored events to subscribers. Subscribers can generate integration (public) events, for which the Gateway component in Eventuous is responsible. Another type of subscriber can project events to other databases for query or analytics purposes. Eventuous supports projecting events to MongoDB, but you can project to any database using custom event handlers.
+
+Please refer to the diagram below for a complete understanding of the process.
+
+<ThemedImage
+    alt="Eventuous way"
+    lightSrc={theRightWay}
+    darkSrc={theRightWayDark}
+/>
+
+## What's wrong with those other diagrams?
+
+Several diagrams that claim to explain Event Sourcing and its implementation often have similar problems, such as:
+
+- Using a bus to propagate domain events to read models
+- Introducing unnecessary components and complexity to the diagram
+- Not using domain events as the source of truth for the domain model state
+- Confusing Event-Driven Architecture (EDA) with Event Sourcing
+
+Let's examine these issues.
+
+### Event bus
+
+Message brokers can be useful for integrating (micro)services through asynchronous messaging, rather than relying on RPC calls. However, the integration aspect is separate from Event Sourcing. Domain events enable message-based integration, but it's not a requirement.
+
+![Bad Bus](images/flaming-bus.jpg)
+
+Using a broker to propagate events to reporting models (read models, query side, etc.) can lead to:
+
+- **Out of order events:** In order to project events to reporting models, it's important that they are processed in the same order as they were produced. Not all message brokers provide this guarantee.
+- **Two-phase commit:** As the database storing the events and the message broker are two separate components, making a single transaction that persists an event and publishes it to the broker can be difficult. One of these operations may fail, causing the system to become inconsistent. While the Outbox pattern can mitigate this issue, its implementation is often more complex than the core system itself.
+- **Replay:** Message brokers are often used for integration, meaning that there are event consumers that react to published events. Unlike reporting models, integration side effects are not idempotent and can't be expected to happen multiple times. When replaying events from the event store to rebuild a single reporting model, other consumers will also be affected and may produce unwanted side effects.
+
+:::caution
+Avoid publishing events to a message broker when handling commands. Instead, ensure that the event store database can support real-time subscriptions and subscribe directly to the event store.
+:::
+
+Publishing events to a message broker from a subscription is a valid scenario. Eventuous provides a component called `Gateway` for that purpose. However, it's recommended to project events by subscribing directly to the event store, rather than building reporting models by consuming from a broker unless it's an event log-based broker like Apache Kafka, Apache Pulsar or Azure Event Hub.
+
+### Using reporting database as system state
+
+Using Reporting Database as System State
+Event Sourcing is a consistent persistence mechanism. An event is appended to the aggregate stream, and the aggregate state is restored by reading these events, which are atomic, consistent, isolated, and durable (ACID).
+
+However, some articles describe Event Sourcing as simply storing events to an ordered log, without using those events as the source of truth. Instead, they project events to another store outside the transaction scope and call it Event Sourcing, but this method does not guarantee consistency. This can result in a delay between when an event is stored and when the state change is reflected in the other database. The latter serves as a reporting model but is not a consistent storage for the system state. In a genuine event-sourced system, the state of any object can always be obtained from the event store and is fully consistent. In a projected store, only a particular state projection is available, which may not be up-to-date. While this is fine for reporting models, it's not suitable for decision-making.
+
+:::caution
+Handling a command results in a state transition of one domain object and the entire system. It's important to operate with a consistent system state when making decisions to execute a command.
+:::
+
+### Event-Driven vs Event Sourcing
+
+Event-Driven Architecture (EDA) is a software design pattern where events, or changes in state, serve as the driving force behind the behavior and interactions of the system's components. In an event-driven system, components communicate with each other by producing and responding to events, rather than by making direct calls to one another. The events are usually managed by a message broker, which is responsible for distributing the events to the appropriate components.
+
+Event Sourcing is a way of persisting the state of a system by storing a sequence of events that represent changes in state, rather than just storing the current state. In event sourcing, the current state of the system is derived from the events that have been recorded.
+
+Although Event Sourcing and EDA are often used together, they are not dependent on each other. It is possible to have an event-driven system without using Event Sourcing to persist state, or an event-sourced system that does not distribute events to the outside. Event Sourcing provides a way to persist state, while EDA is about integrating system components using events. Both Event Sourcing and EDA have their own benefits and trade-offs, and the choice of whether to use one, both, or neither will depend on the specific requirements of the system being developed.
diff --git a/docs/src/content/docs/0.15/read-models/rm-concept.md b/docs/src/content/docs/0.15/read-models/rm-concept.md
new file mode 100644
index 000000000..92363d1b7
--- /dev/null
+++ b/docs/src/content/docs/0.15/read-models/rm-concept.md
@@ -0,0 +1,132 @@
+---
+title: "Concept"
+description: "The concept of read models"
+---
+
+## Queries in event-sourced systems
+
+As described [previously](../../domain/aggregate), the domain model is using [events](../../domain/domain-events) as the _source of truth_. These events represent individual and atomic state transitions of the system. We add events to [event store](../../persistence/event-store) one by one, in append-only fashion. When restoring the state of an aggregate, we read all the events from a single stream, and apply those events to the aggregate state. When all events are applied, the state is fully restored. This process takes nanoseconds to complete, so it's not really a burden.
+
+However, when all you have in your database is events, you can hardly query the system state for more than one object at a time. The only query that the event store supports is to get one event stream using the aggregate id. In many cases, though, we need to query using some other attribute of the aggregate state, and we expect more than one result. Many see it as a major downside of Event Sourcing, but, in fact, it's not a big problem.
+
+When building an event-sourced system, after some initial focus on the domain model and its behaviour, you start to work on queries that provide things like lists of objects via an API, so the UI can display them. There you need to write queries, and that's where the idea of CQRS comes in.
+
+## CQRS (do you mean "cars"?)
+
+The term CQRS was coined more than a decade ago by [Greg Young](https://twitter.com/gregyoung), who also established a lot of practices of Event Sourcing as implemented by Eventuous.
+
+:::note
+**CQRS** stands for **C**ommand-**Q**uery **R**esponsibility **S**egregation.
+:::
+
+The concept can be traced back in time to a separation between operational and reporting store:
+
+> [The main] database supports operational updates of the application's state, and also various reports used for decision support and analysis.
+> The operational needs and the reporting needs are, however, often quite different - with different requirements from a schema and different data access patterns. When this happens it's often a wise idea to separate the reporting needs into a reporting database...
+> 
+> [ReportingDatabase](https://martinfowler.com/bliki/ReportingDatabase.html) - Martin Fowler's bliki
+
+Greg argues that it's not a requirement to separate two databases, but it's a good idea to at least understand that the need for transactional updates requires a different approach compared with reporting needs. Say, you use something like EntityFramework to persist your domain entities state. Although it works quite well, it's not a good idea to use it for reporting purposes. You'd be limited to reach the data using EntityFramework's DbContext, when in reality you'd want to make more direct queries, joining different tables, etc.
+
+:::note[What's up with CARS?]
+Where "did you mean CARS?" comes from? When CQRS wasn't as popular term, Google search assumed you made a mistake and proposed to search for "cars" instead.
+:::
+
+### CQRS and Event Sourcing
+
+In real life, CQRS in event-sourced system means that you will have to separate the operation and the reporting stores. It is because querying the state of a single aggregate is not the only query you'd like to do. You might want to query across multiple aggregates, or across different aggregate types. In addition, you don't always need to return the full aggregate state, but only a subset of it.
+
+That's where read models come in. Read models are _projections_ of the system state, which are built based on the query needs. Therefore, we sometime reference them as _views_, or _query models_. You'd normally use some other database than your event store database for storing read models, and that database needs to support rich indexing and querying.
+
+## Benefits of read models
+
+In state-based systems you normally have access to the state of your domain object in a very optimized, normalized schema. When executing a query over a normalized database, you'd often need to build a comprehensive set of joins across multiple tables or collections, so you can get all the required information in one go. That approach is not always optimal. Let's say you want to display a widget that shows the number of reservations made for a given hotel during the last 30 days. You'd need to run a count query across the reservations table, and then a join across the hotels table to get the hotel name.
+
+Now imagine all the reservations made are represented as events. By _projecting_ those events to a read model that just calculates the number of reservations made for the last 30 days per hotel, you can get the same result in a much more efficient way. When you have a read model, you can do the same query in a single query, without the need to build joins. You'd just need to run a query against the read model, and it would return the required information in a single query, just using the hotel id as a single query argument.
+
+You could see this approach as the normalization of an operational database schema. However, it's not the only thing that happens. When building read models, you are no longer bound to the primary key of the aggregate that emits state transitions. You can use another attribute as the primary key, or even a composite key. For example, with the number of reservations of a hotel, you could use the hotel id and the date of the reservation as the read model primary key.
+
+The point here is that when building read models, you'd normally start designing them based on the needs of the query, not the needs of the database schema. The query needs most often come from the user interface requirements for data visualizations, which are often orthogonal to the operational needs of the domain model. Read model allows you to find a balance between operational and reporting needs without sacrificing the explicitness of the model for the richness and effectiveness of the query model.
+
+Here are some examples of the read models that can be built for a given domain model:
+- My reservations (per guest)
+- My past stays (per guest)
+- My upcoming stays (per guest)
+- Upcoming arrivals (per hotel)
+- Cancellations for the last three months (per hotel)
+
+Built as read models, all those queries can be run in a single query, without the need to build joins over multiple tables and potentially thousands of rows or documents.
+
+## How to build a read model?
+
+For building read models, you need to receive events from the event store and project them real time to a queryable store. Let's say that we have two event types:
+
+```
+record RoomBooked(
+    string BookingsId,
+    string RoomId,
+    string GuestId,
+    DateOnly CheckIn,
+    DateOnly CheckOut,
+    float Price
+);
+
+record BookingCancelled(
+    string BookingId,
+    string Reason
+)
+```
+
+We want to project those events to MongoDB, so we can issue queries across all the bookings. It can be done by projecting all the `RoomBooked` events to a `Bookings` collection. The document structure would be identical to the event contract for now.
+
+So, we can create a subscription and add an event handler that would create a new `Booking` document in the collection when it receives an `RoomBooked` event. It would use the `BookingId` as the document id (`_id`) field in MongoDB. When using Eventuous, it's important to remember that it does not enforce _exactly one_ event processing rule (although it can), as it would have a negative impact on the subscription's performance. Therefore, when the handler has processed an event, it might eventually need to process it again when the application restarts after a crash. It might sound a bit scary, but in reality, those events will be delivered again in the same order, and it's easy to mitigate the issue by ensuring that the projection handler is idempotent. For our example, we could do that by using `updateOne` operation with the option `isUpsert` set to `true` instead of using the `insertOne` operation. Any update operation is by definition idempotent as long as it doesn't use operations on the existing state like `inc` or `dec`. That's why it's essential to only use event properties in updates, so the event needs to contain enough information for the projecting handler to execute the update without using the current projected document state.  
+
+If we decide that we don't want to have cancelled bookings in that collection, we would add a new event handler to the same subscription. This new handler would remove the document from the collection when it receives `BookingCancelled` and use the `Eq` filter, so it deletes the document where the document id equals the `BookingId` property of the event.
+
+## Consistency concerns
+
+The data in a query database is updated when the projecting subscription receives and processes the event. It means that there's a delay between the operation is completed on the command side, when the result is returned to the caller, and the read model update. Under normal circumstances, this delay doesn't exceed a couple of hundred milliseconds. However, when the query store is unable to process updates as fast as the events arrive, the delay starts to increase (see [Mind the Gap](../../subscriptions/subs-diagnostics)).
+
+Due to this delay, the users of your system might experience a situation that when they submit a command and get completion the result back, the query doesn't return the latest changes because these changes haven't propagated to the read model yet. In the context of Event Sourcing, this phenomenon is often called _eventual consistency_.
+
+However, the definition of eventual consistency has little in common with what's described above. According to [Wikipedia](https://en.wikipedia.org/wiki/Eventual_consistency), eventually-consistent services are often classified as providing BASE semantics (basically-available, soft-state, eventual consistency). The original meaning of eventual consistency implies that there's a distributed system with multiple nodes accepting writes, and those nodes need to get some operational slack for replicating changes mutually. However, subscriptions in event-sourced systems don't use this model. Projecting events cannot even be called "replication" as such. Instead, projections transform each event to a state update, and execute the state update transactionally in another database. These updates are also executed sequentially, and, when following best practices, replaying a set of events again would result in idempotent updates. In this sense, the read store cannot be in a state of conflict (as there's only one), and it can't contain _invalid_ data, but it can contain _stale_ data.
+
+Another point of criticism of the potential staleness of read models is about RYW (read your writes) session guarantee. The claim here is that when you execute a command (write) and then run a query immediately after (read), you might get a stale result, so you don't see your write. Outside the scope of read models this claim is nonsense. For example, if you execute two consecutive writes in an event-sourced system, the second write will first read the result of the previous write, and the result will never be stale. It's because all the commands in a properly built event-sourced system use events as the source of truth, and they always read from the event store, which is a transactional, fully consistent database.
+
+In fact, when a larger system with several components uses the same event store that implements the concept of a global sequential append-only event log, and when handling commands all the entities are solely retrieved from event streams, the system will exhibit characteristics of a strong consistency type called _sequential consistency_.
+
+:::tip
+You can read more about different consistency types [here](https://jepsen.io/consistency).
+:::
+
+It is, therefore, important to understand that in CQRS world you'd need to deal with more than one system component, and more than one database (when we talk about Event Sourcing). Even if you build a single, monolithic application, you'll find yourself dealing with issues similar to those normally found in distributed systems, and those issues need to be worked with using methods and practices that are established in the distributed world. 
+
+## Dealing with stale data
+
+There are a few aspects of dealing with stale data that you'd need to consider when building read models, and exposing queries on top of them.
+
+### Is it a problem?
+
+The first question to ask is exactly this: "is it really a problem?" For example, many systems today are built in a form-list fashion. You see a list of things, and there's an "Add" button there. When you click on it, you get a form. After filling out the necessary details in the form, you click a "Submit" or "Save" button, then you get redirected back to the same list. Naturally, if the list is fed by a query to the read model store, and the subscription for the read model projection takes 200ms to process one event, but the redirect takes 10ms, you will not find the new entry in the list.
+
+The question here is if this is a good user experience at all when you need to search for a new entry in the potentially long list when you just added it. There are quite a few ways to provide a better experience, and the most popular one is to present the user with the new entry in read-only mode and there have a link "Back to the list".
+
+Many systems expose multi-stage forms, where each stage is a logically-complete step in some workflow. There, you'd prefer to send a command for each stem in the flow. By doing that you eliminate the risk that the user will get a failure and lose all the entered data if a single "Submit" step fails. You'd also have at least some information projected to the read model as the user goes through the steps.
+
+Other kinds of systems don't use lists as the primary entry point for their users. Think about hotel bookings and flight reservations. You fill out a form, get through the payment process (by that time your booking is already stored and awaits for the payment update), and then you get a "Thank you" screen with the booking number. You might never see the list of your flight reservations right after that as it's often a completely different part of the system where you need to navigate manually.
+
+If you build a system that can behave without a "classic" (but often horrible) list-form flow, you might not need to care about your read models being stale as a normally functioning projection will get the read model updated way before the user gets to it.
+
+### Define an SLA
+
+In some cases, you have a requirement that the query model needs to be updated _immediately_ after the command has been executed. The "immediate" feeling urges the developer to start optimizing things. However, you should be asking "what _immediately_ means", and this question needs to be addressed to domain experts. Most often than not, after taking some time to think, they can provide a meaningful SLA instead of "immediately", as _nothing_ happens "immediately" anyway. Within the defined SLA you might need to optimize things, but the level of effort might be not as significant as you originally anticipated. You can also set up proper monitoring and alerting for measuring the projection staleness within the SLA. Eventuous provides enough tools out of the box to do that.
+
+### Stop forgetting things
+
+Not all user interfaces are built stateless. With the rise of single-page application frameworks such as React and VueJS, the user's browser holds quite a lot of state. That state can be used for remembering things. Think about that form again, haven't you got the [new entity state](../../application/app-service#result) from Eventuous after calling the HTTP API? Why can't it be used to update the existing client-side application state instead of querying it from the server again? When using state management tools like Redux or VueX you can even propagate events received in the `Result` object to the client-side application state using the store reducers (which are, effectively, event handlers). This way, you can even improve the cohesiveness of the whole system by letting its front- and back-end to use the same events, using the same Ubiquitous Language.
+
+### Wait
+
+Sometimes you can't control the UI, but you do control the query API, and you know that the UI works in the form-list fashion. There's a clear risk that when the user gets redirected to the list after submitting the form, they won't find the new or updated information in the list. In that case, you can use the command handling result combined with the projected item `Position` property. For example, the [MongoDB projection](../../infra/mongodb) implicitly updates the read model document `Position` property with the projected event global log position. When the command is handled successfully by the command service, you get the `OkResult` record instance back. There, you find the `StreamPosition` property, which points to the last appended event global position. You can then query your read model store for a specific read model that feeds the list where the user will be redirected to. When you find out that the document in that read model got updated with the `Position` property higher or equal the returned `StreamPosition` value, you can return `200 OK` result to the API call. Until then, you just wait. By doing this, you will ensure that the list that the user will see after handling the command will contain the updated information.
+
+You can also query the checkpoint store for a given read model to see if the stored checkpoint surpasses the one you get in the `OkResult` object. But then, you need to be sure that the subscription is listening to the global event stream (it won't work if you use, for example, the category stream in EventStoreDB), and the checkpoint is not batched (it's batched by default). We don't recommend using this approach.
diff --git a/docs/src/content/docs/0.15/read-models/supported-projectors.md b/docs/src/content/docs/0.15/read-models/supported-projectors.md
new file mode 100644
index 000000000..590dd4f1c
--- /dev/null
+++ b/docs/src/content/docs/0.15/read-models/supported-projectors.md
@@ -0,0 +1,12 @@
+---
+title: Supported projectors
+description: Built-in projectors supported by Eventuous.
+---
+
+Eventuous supports the following projection targets:
+
+- [MongoDB projections](../../infra/mongodb)
+- [PostgreSQL projections](../../infra/postgres#projections)
+- [Microsoft SQL Server projections](../../infra/mssql#projections)
+
+You can project to any other database using a custom projector, which can be built as a [custom event handler](../../subscriptions/eventhandler#custom-handlers).
\ No newline at end of file
diff --git a/docs/src/content/docs/0.15/subscriptions/checkpoint.mdx b/docs/src/content/docs/0.15/subscriptions/checkpoint.mdx
new file mode 100644
index 000000000..b28662449
--- /dev/null
+++ b/docs/src/content/docs/0.15/subscriptions/checkpoint.mdx
@@ -0,0 +1,127 @@
+---
+title: "Checkpoints"
+description: "What's a checkpoint and why you need to store it"
+---
+import ThemedImage from '@components/ThemedImage.astro';
+import commitHandler from './images/commit-handler.png';
+import commitHandlerDark from './images/commit-handler-dark.png';
+
+When subscribing to an event store, it is important to consider which events you wish to receive. An effective event store should allow you to subscribe to individual event streams or to a global stream known as the "All stream", which contains all events in the store, organized in the order they were recorded. Many event-driven brokers that persist events as ordered logs also support subscriptions, which are often referred to as "consumers".
+
+The subscription you choose will determine at what point in the stream you begin to receive events. If you want to process all historical events, it is necessary to subscribe from the beginning of the stream. However, if you only wish to receive real-time events, it is necessary to subscribe from the current point in time.
+
+## What's the checkpoint?
+
+As the subscription receives and processes events, it progresses along the subscribed stream. Each event that is received and processed has a unique position within the stream, which serves as a checkpoint for the subscription. If the application hosting the subscription shuts down, it is necessary to resume processing events from the last recorded checkpoint, which is the position of the last processed event plus one. This ensures that each event is handled exactly once. As a result, the subscription must keep track of its checkpoint, either by storing it in a dedicated checkpoint store or by using the event store's built-in functionality.
+
+In some log-based brokers, the concept of a checkpoint is referred to as an "offset". Some event-driven brokers manage subscriptions on the server-side, eliminating the need for client-side checkpoint storage. For example, persistent subscriptions in EventStoreDB and subscriptions in Google PubSub do not require a client-side checkpoint store. Other subscriptions, such as those managed by RabbitMQ, do not have the concept of a checkpoint as RabbitMQ does not retain consumed messages, whether they have been acknowledged or not.
+
+## Checkpoint store
+
+Eventuous offers an abstraction layer that enables subscriptions to store checkpoints securely and reliably. You can choose to store the checkpoint in a file or database and determine the frequency at which you wish to store the checkpoint, whether after processing each event or periodically. Although periodic checkpoint storage reduces the stress on the infrastructure supporting the checkpoint store, it requires the subscription to be idempotent. This can be challenging, especially in integration scenarios where it is often difficult or impossible to determine if an event has been published to the broker or not. However, this approach may work for read model projections.
+
+:::caution[Keep the checkpoint safe]
+It is important to keep the checkpoint safe, as its loss will result in the subscription receiving all events. This may be intentional when creating a new [read model](../../read-models/rm-concept), but it can also have unintended consequences in other scenarios.
+:::
+
+On top of the abstraction Eventuous provides a few implementations of the checkpoint store, which you can use out of the box. You can also implement your own checkpoint store if you need to store the checkpoint in a custom location.
+
+### Abstraction
+
+The checkpoint store interface is simple, it only has two functions:
+
+```csharp title="ICheckpointStore.cs"
+interface ICheckpointStore {
+    ValueTask<Checkpoint> GetLastCheckpoint(
+        string checkpointId,
+        CancellationToken cancellationToken
+    );
+
+    ValueTask<Checkpoint> StoreCheckpoint(
+        Checkpoint checkpoint,
+        CancellationToken cancellationToken
+    );
+}
+```
+
+The `Checkpoint` record is a simple record, which aims to represent a stream position in any kind of event store:
+
+```csharp
+record Checkpoint(string Id, ulong? Position);
+```
+
+### Available stores
+
+If a supported projection type in an Eventuous package for projections requires a checkpoint store, you can find its implementation in that package. For example, the `Eventuous.MongoDB` package has a checkpoint store implementation for MongoDB.
+
+If you register subscriptions in the DI container, you also need to register the checkpoint store:
+
+```csharp title="Program.cs"
+builder.Services.AddSingleton<IMongoDatabase>(Mongo.ConfigureMongo());
+builder.Services.AddCheckpointStore<MongoCheckpointStore>();
+```
+
+In case you have multiple subscriptions in one service, and you project to different databases (for example, MongoDB and PostgreSQL), you need to specify the checkpoint store for each subscription. In this case, you don't need to register the checkpoint store globally in the DI container, but use the `UseCheckpointStore` method when building your subscription:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    builder => builder
+        .Configure(cfg => cfg.ConcurrencyLimit = 2)
+        .UseCheckpointStore<MongoCheckpointStore>()
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>()
+        .WithPartitioningByStream(2)
+);
+```
+
+#### MongoDB
+
+The MongoDB checkpoint store will create a collection called `checkpoint` where it will keep one document per subscription.
+
+Each checkpoint document contains the checkpoint id, which is the subscription id. Therefore, you only get one `checkpoint` collection per database.
+
+#### Elasticsearch
+
+The Elasticsearch checkpoint store will create and use the `checkpoint` index, and the document id there would be the subscription id.
+
+#### PostgreSQL
+
+The Postgres checkpoint store will create and use the `checkpoint` table, and the row id there would be the subscription id. Here is the script used to create that table:
+
+```sql
+create table if not exists __schema__.checkpoints (
+    id varchar primary key, 
+    position bigint null 
+);
+```
+
+#### Other stores
+
+In addition to that, Eventuous has two implementations in the core subscriptions package:
+- `MeasuredCheckpointStore`: creates a trace for all the IO operations, wraps an existing store
+- `NoOpCheckpointStore`: does nothing, used in Eventuous tests
+
+The measured store is used by default if Eventuous diagnostics aren't disabled, and you use the `AddCheckpointStore` container registration extension.
+
+## Checkpoint commit handler
+
+In addition to checkpoint store, Eventuous has a more advanced way to work with checkpoints. It doesn't load or store checkpoints by itself, for that purpose it uses the provided checkpoint store. However, the commit handler is able to receive a stream of unordered checkpoints, reorder them, detect possible gaps, and only store the checkpoint that is the latest before the gap.
+
+For subscriptions that support delayed consume (see [Partitioning filter](../pipes/#partitioning-filter)) and require a checkpoint store, you must use the commit handler. All such subscription types provided by Eventuous use the checkpoint commit handler.
+
+Unless you create your own subscription with such requirements, you don't need to know the internals of the commit handler. However, you would benefit to know the consequences of delayed event processing with supported subscriptions.
+
+When events get partitioned by the filter, several consumer instances process events in parallel. As a result, each partition will get checkpoints with gaps. When partitioned consumers process events, they run at different speed. Each event inside `DelayedConsumeContext` is explicitly acknowledged, and when it happens, the checkpoint gets to the commit handler queue. The commit handler then is able to accumulate checkpoints, detect gaps in the sequence, and only store the latest checkpoint in a gap-less sequence.
+
+<ThemedImage
+    alt="Gap in the commit handler queue"
+    lightSrc={commitHandler}
+    darkSrc={commitHandlerDark}
+/>
+
+:::note
+On the illustration above, the commit queue has a gap, and event **95** is still in-flight. As soon as the event **95** is processed, its position will get to the queue, the commit handler will detect a gap-less sequence, and commit the checkpoint **97**.
+:::
+
+As we talk about gaps, you might face a situation when the commit handler has a list of uncommitted checkpoints with gaps, and the application stops. When this happens, some events were already processed, whilst checkpoints for those events remain in-flight. When the application restarts, it loads the checkpoint that points to some position in the stream that is _earlier_ than positions of already processed events. Because of that, some events will be processed by event handlers _again_. Therefore, you need to make sure that your event handlers are _idempotent_, so when the same events are processed again, the result of the processing won't create any undesired side effects.
diff --git a/docs/src/content/docs/0.15/subscriptions/eventhandler.md b/docs/src/content/docs/0.15/subscriptions/eventhandler.md
new file mode 100644
index 000000000..339f5243c
--- /dev/null
+++ b/docs/src/content/docs/0.15/subscriptions/eventhandler.md
@@ -0,0 +1,96 @@
+---
+title: "Event handlers"
+description: "The last bit of the subscription process"
+---
+
+Event handlers are the final step in the subscription event processing [pipeline](../pipes). Each subscription has a single consumer that holds a collection of event handlers added to the subscription. The consumer calls all the event handlers simultaneously, collects the results, and then acknowledges the event to the subscription.
+
+One common example of an event handler is a [read model](../../read-models/rm-concept) projector. Eventuous currently supports projecting events to MongoDB, but you can use any other database or file system.
+
+## Abstractions
+
+The default consumer holds classes that implement the basic interface of an event handler, defined as:
+
+```csharp title="IEventHandler.cs"
+public interface IEventHandler {
+    string DiagnosticName { get; }
+
+    ValueTask<EventHandlingStatus> HandleEvent(IMessageConsumeContext context);
+}
+```
+
+The `DiagnosticName` property provides information that is used in log messages when the handler processes or fails to process the event. The `HandleEvent` function is called for each event received by the consumer and contains the actual event processing code. It should return a result of type `EventHandlingResult`.
+
+The `BaseEventHandler` abstract class is commonly used as the base class for all event handlers, including custom ones, instead of implementing the interface directly. This class sets the DiagnosticName property to the type name of the event handler class.
+
+Higher-level event handlers in Eventuous, such as `MongoProjection` and `GatewayHandler`, inherit from the `BaseEventHandler`.
+
+## Handler results
+
+A handler typically returns `Success` if the event was handled successfully, `Error` if the event handling failed, or `Ignored` if the handler has no code to process the event. The consumer determines the combined result based on the results returned by the handlers:
+
+- Ignored events are considered processed successfully
+- If all events are processed successfully, the consumer acknowledges the event
+- If one or more handlers return an error, the consumer considers it an error and explicitly NACKs the event.
+- 
+The outcome of events that were not acknowledged by the consumer depends on the subscription type and its configuration.
+
+## Custom handlers
+
+If you need to implement a custom handler, such as a projector to a relational database, you typically use the `EventHandler` abstraction provided by Eventuous. This abstraction allows you to register typed handlers for specific event types in a map, and the HandleEvent function is already implemented in the interface, which will call the registered handler or return Ignored if no handler is registered for a given event type.
+
+The `EventHandler` base class takes a [`TypeMapper`](../../persistence/serialisation#type-map) instance as a constructor argument. If a constructor argument is not provided, the default type mapper instance will be used. The `On<TEvent>` function uses the type mapper to check if the event type `TEvent` is registered in the type map, thus proactively causing the program to crash during startup if a handler is defined for an unregistered event type.
+
+As an example, consider a simple handler that prints *$$$ MONEY! You got USD 100!* to the console when it receives the `PaymentRegistered` event, where the event's paid amount property is 100 and its currency is USD.
+
+```csharp title="MoneyHandler.cs"
+class MoneyHandler : EventHandler {
+    public MoneyHandler(TypeMapper? typeMap = null) : base(typeMap) {
+        On<PaymentRegistered>(
+            async context => {
+                await Console.Out.WriteLineAsync(
+                    $"$$$ MONEY! You got {context.Message.Currency} {context.Message.AmountPaid}"
+                );
+            }
+        );
+    }
+}
+```
+
+Another example would be a base class for a projector, which would use the handlers map and allow adding extended handlers for projecting events to a query model. Below is an example of a base class for a Postgres projector:
+
+```csharp title="PostgresProjector.cs"
+public abstract class PostgresProjector : EventHandler {
+    readonly GetPostgresConnection _getConnection;
+
+    protected PostgresProjector(
+        GetPostgresConnection getConnection, 
+        TypeMapper? mapper = null) : base(mapper) {
+        _getConnection = getConnection;
+    }
+
+    protected void On<T>(ProjectToPostgres<T> handler) where T : class {
+        base.On<T>(async ctx => await Handle(ctx).NoContext());
+
+        async Task Handle(MessageConsumeContext<T> context) {
+            await using var connection = _getConnection();
+            await connection.OpenAsync(context.CancellationToken).ConfigureAwait(false);
+            var cmd = await handler(connection, context).ConfigureAwait(false);
+            await cmd.ExecuteNonQueryAsync(context.CancellationToken).ConfigureAwait(false);
+        }
+    }
+}
+
+public delegate Task<NpgsqlCommand> ProjectToPostgres<T>(
+    NpgsqlConnection connection, 
+    MessageConsumeContext<T> consumeContext)
+    where T : class;
+```
+
+## Registering handlers
+
+For an event handler to work, it needs to be added to a subscription. The `AddHandler` function on the subscription registration builder takes an instance of the `IEventHandler` interface as an argument. The `AddHandler` function is overloaded to accept a handler instance or a factory function that returns a handler instance.
+
+You can find examples of adding handlers to subscriptions in the [subscription documentation](../sub-base/#registration).
+
+Built-in projectors are event handlers, and they are added to the subscription in the same way as custom handlers.
diff --git a/docs/src/content/docs/0.15/subscriptions/images/commit-handler-dark.png b/docs/src/content/docs/0.15/subscriptions/images/commit-handler-dark.png
new file mode 100644
index 000000000..7e207a483
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/commit-handler-dark.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/commit-handler.png b/docs/src/content/docs/0.15/subscriptions/images/commit-handler.png
new file mode 100644
index 000000000..9d2dce1fd
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/commit-handler.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/concurrent-filter-dark.png b/docs/src/content/docs/0.15/subscriptions/images/concurrent-filter-dark.png
new file mode 100644
index 000000000..692216b2e
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/concurrent-filter-dark.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/concurrent-filter.png b/docs/src/content/docs/0.15/subscriptions/images/concurrent-filter.png
new file mode 100644
index 000000000..eddf9d72b
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/concurrent-filter.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/default-pipe-dark.png b/docs/src/content/docs/0.15/subscriptions/images/default-pipe-dark.png
new file mode 100644
index 000000000..3b1158783
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/default-pipe-dark.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/default-pipe.png b/docs/src/content/docs/0.15/subscriptions/images/default-pipe.png
new file mode 100644
index 000000000..c62791d37
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/default-pipe.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/partitioning-filter-dark.png b/docs/src/content/docs/0.15/subscriptions/images/partitioning-filter-dark.png
new file mode 100644
index 000000000..13eafbd87
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/partitioning-filter-dark.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/partitioning-filter.png b/docs/src/content/docs/0.15/subscriptions/images/partitioning-filter.png
new file mode 100644
index 000000000..feac40e59
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/partitioning-filter.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/sub-trace.png b/docs/src/content/docs/0.15/subscriptions/images/sub-trace.png
new file mode 100644
index 000000000..d98c5a8fa
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/sub-trace.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/subscriptions-dark.png b/docs/src/content/docs/0.15/subscriptions/images/subscriptions-dark.png
new file mode 100644
index 000000000..155d09b36
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/subscriptions-dark.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/images/subscriptions.png b/docs/src/content/docs/0.15/subscriptions/images/subscriptions.png
new file mode 100644
index 000000000..b0321e607
Binary files /dev/null and b/docs/src/content/docs/0.15/subscriptions/images/subscriptions.png differ
diff --git a/docs/src/content/docs/0.15/subscriptions/pipes.mdx b/docs/src/content/docs/0.15/subscriptions/pipes.mdx
new file mode 100644
index 000000000..14e718a61
--- /dev/null
+++ b/docs/src/content/docs/0.15/subscriptions/pipes.mdx
@@ -0,0 +1,112 @@
+---
+title: "Consume pipe"
+description: "Subscription consume pipes and filters"
+sidebar:
+  order: 527
+---
+import ThemedImage from '@components/ThemedImage.astro';
+import defaultPipe from './images/default-pipe.png';
+import defaultPipeDark from './images/default-pipe-dark.png';
+import concurrentFilter from './images/concurrent-filter.png';
+import concurrentFilterDark from './images/concurrent-filter-dark.png';
+import partitioningFilter from './images/partitioning-filter.png';
+import partitioningFilterDark from './images/partitioning-filter-dark.png';
+
+## Pipes and filters
+
+When a subscription gets a message from the transport, it will create a consume context with the message itself, and some contextual information like message id, message type, subscription id, etc. Then, it will pass it over to the consume pipe. A pipe is a set of filters, which are executed sequentially, like middlewares. Each filter can do something with the context, and then calls the next filter. The process continues until there are no filters left. By that time, the message is considered consumed, and the pipe finishes.
+
+Eventuous consume pipe can be customised by adding filters to it, but normally you'd use the default pipe, which can be visualized like this:
+
+<ThemedImage
+    alt="Default consume pipeline"
+    lightSrc={defaultPipe}
+    darkSrc={defaultPipeDark}
+/>
+
+Some subscriptions conditionally or unconditionally add filters to the pipe, when they detect the default pipe. For example, EventStoreDB catch-up subscription might add the concurrent filter and partitioning filter, and RabbitMQ subscription uses the concurrent filter.
+
+## Available filters
+
+Eventuous has two interfaces for filters, but all the provided filters are based on `ConsumeFilter` and `ConsumeFilter<T>` base classes. There, `<T>` is the context type, as some filters can only process certain context types. The validation of filter vs context type matching is done when the pipeline is constructed, so it won't fail at runtime.
+
+Out of the box, you can find the following filters:
+- `ConsumerFilter`: (mandatory) the final filter in the pipe, which hosts the consumer
+- `MessageFilter`: (optional) allows filtering out messages based on context data (message type, meta, payload, etc.)
+- `TracingFilter`: (optional) traces the event handling process, added by default when diagnostics aren't disabled
+- `ConcurrentFilter`: (optional) allows splitting message processing from the subscription
+- `PartitioningFilter`: (optional) allows parallel message processing with partitions
+
+### Consumer filter
+
+The consumer filter holds an instance of the message consumer. By default, Eventuous uses the `DefaultConsumer`, and it doesn't require any configuration. You can override that using the `UseConsumer<T>()` function of the subscription builder when you register a subscription.
+
+The default consumer Acks the message when all the handlers processed the message without failures, and at least one handler didn't ignore the message. It Nacks the message if any handler returned an error or crashed. Finally, it will ignore the message if all the handlers ignored it. How the message handling result is processed is unknown to the consumer as this behaviour is transport-specific. Each subscription type has its own way to process the message handling result.
+
+When building a custom consumer, you'd need to include similar event handling result logic into it.
+
+The consumer filter is a mandatory filter that should be the final filter in the pipe. When you register a subscription, the consumer filter is added to the pipe by default.
+
+### Message filter
+
+The message filter can be used to prevent some messages from going down the pipe by filtering those messages out. When constructed, it needs a single constructor argument, which is a filtering function. The function gets an instance of `IMessageContext`, so it can use all of its available properties to filter messages. When the message is filtered out, the filter will mark it as ignored.
+
+Example:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<StreamSubscription, StreamSubscriptionOptions>(
+    "nonFooSubscription",
+    cfg => cfg.AddConsumeFilterFirst(new MessageFilter(x => !x.MessageType.StartWith("foo")))
+);
+```
+
+Such a subscription will ignore all the events that have the type starting with "foo".
+
+### Tracing filter
+
+The tracing filter gets added automatically when Eventuous diagnostics is enabled (or, not disabled, as it's enabled by default). Read more about Eventuous tracing in the [Diagnostics](../../diagnostics) section.
+
+### Concurrent filter
+
+When using the concurrent filter, the pipe gets separated in two parts: before the concurrent filter and after it. The filter itself creates a channel of a given size (100 by default), where it puts all the messages in order. Then, the pipeline returns to the subscription as if the message was already consumed. A parallel process fetches messages from the channel continuously, and sends them to the second part of the pipe where messages actually gets consumed.
+
+Because of such a split, the result returned to the subscription doesn't contain the actual handling result. Therefore, the concurrent filter can only be used in combination with `DelayedAckConsumeContext`. It's the responsibility of a subscription to create such a context type, so only some subscription types support using the concurrent filter. This context type has two additional functions to Ack (`Acknowledge` function) or Nack (`Fail` function) each message. The subscription provides specific implementations of those functions. For example, an EventStoreDB catch-up subscription would commit the checkpoint when the event is acknowledged. The filter calls these functions itself, based on the result returned by the second part of the pipe (delayed consume).
+
+<ThemedImage
+    alt="Pipe with concurrent filter"
+    lightSrc={concurrentFilter}
+    darkSrc={concurrentFilterDark}
+/>
+
+The concurrent filter is useful in combination with partitioning filter, but it can also be used for other purposes, like batched event processing.
+
+Subscriptions that support delayed consume add this filter by default when necessary (based on the subscription configuration). Usually, you'd need to set the `ConcurrencyLimit` property of the subscription options to a value greater than 1 to enable the concurrent filter.
+
+:::caution
+Do not set the `ConcurrencyLimit` property when using the partitioning filter.
+:::
+
+### Partitioning filter
+
+Sometimes the subscription workload gets too high for it to cope with the number of delivered messages, and process them fast enough one by one. In this case, the partitioning filter can be useful as it allows handling messages in parallel. Most of the time you'd want the messages to be delivered in order within some partition. For example, it is often important to process messages from a single aggregate in order. To support that, you can use the stream name (which contains the aggregate id) as the partition key.
+
+<ThemedImage
+    alt="Pipe with concurrent and partitioning filters"
+    lightSrc={partitioningFilter}
+    darkSrc={partitioningFilterDark}
+/>
+
+You can use two options for configuring the filter:
+- Provide a function that calculates the partition hash
+- Provide a function that returns the partition key
+- Provide nothing
+
+Using the second option is easier as you don't need to calculate the hash, it's enough to return something like stream id. In that case, the filter will use `MurmurHash3` to calculate the hash for a given partition key.
+
+The third option will use the default partition key function that uses the message stream as partition key.
+
+All those options require the number of partitions provided as an argument.
+
+As the partitioning filter processes messages in multiple threads, it cannot provide the global processing order. The order of processing is guaranteed within a partition. Due to that fact, it needs to be able to Ack or Nack messages individually, without maintaining global order. Therefore, it only works with `AsyncConsumeContext`, and it's often used with the concurrent filter for best performance. As you can imagine, partitioning can only be used for subscriptions that support delayed consume.
+
+Subscriptions that support delayed consume add this filter by default when necessary (based on the subscription configuration) together with the concurrent filter. Check the particular transport subscription implementation to learn more.
diff --git a/docs/src/content/docs/0.15/subscriptions/sub-base.md b/docs/src/content/docs/0.15/subscriptions/sub-base.md
new file mode 100644
index 000000000..26151d198
--- /dev/null
+++ b/docs/src/content/docs/0.15/subscriptions/sub-base.md
@@ -0,0 +1,116 @@
+---
+title: "Subscription base"
+description: "How Eventuous subscriptions work"
+sidebar:
+  order: 2
+---
+
+The base abstract class for subscriptions is the `IMessageSubscription` interface, but all the available subscriptions are based on the `EventSubscription` base class, which is a generic abstract class where its type parameter is the subscription options type. All the provided subscription options types inherit from the `SubscriptionOptions` base class.
+
+The `SubscriptionOptions` base class has three properties:
+* `SubscriptionId`: a unique identifier for the subscription
+* `ThrowOnError`: a boolean indicating whether the subscription should throw an exception if an error occurs. When the subscription throws, it either NACKs the message, or stops the subscription depending on the implementation.
+* `EventSerializer`: an instance of the `IEventSerializer` interface, which is used to serialize and deserialize events. If not provided, the default serializer is used.
+
+Each provided subscription options type has more options, which depend on the subscription implementation details.
+
+To host a subscription and manage its lifecycle, Eventuous has a hosted service called `SubscriptionHostedService`. Each registered subscription gets its own hosted service, so that each subscription can be managed independently. When using Eventuous subscription registration extensions for the DI container, the hosted service is registered automatically.
+
+You'd normally use the DI container to register subscriptions with all the necessary handlers (described below).
+
+## Event handlers
+
+As mentioned on the [Concept](../subs-concept) page, one subscription might serve multiple event handlers, such as projections. It is especially relevant to keep a group of projections in sync, so they don't produce inconsistent [read models](../../read-models/rm-concept).
+
+Each subscription service gets a list of event handlers. An event handler must implement the `IEventHandler` interface, which has two members:
+
+```csharp
+public interface IEventHandler {
+    string DiagnosticName { get; }
+    ValueTask<EventHandlingStatus> HandleEvent(IMessageConsumeContext context);
+}
+```
+
+The `HandleEvent` function will be called by the subscription service for each event it receives. The event is already deserialized. The function also gets the event position in the stream. It might be used in projections to set some property of the read model. Using this property in queries will tell you if the projection is up-to-date.
+
+:::caution[Event handler failures]
+If an event handler throws, the whole subscription will fail. Such a failure will cause the subscription drop, and the subscription will resubscribe. If the error is caused by a poison event, which can never be handled, it will keep failing in a loop. You can configure the subscription to ignore failures and continue by setting `ThrowIfError` property of `SubscriptionOptions` to `false`.
+:::
+
+The diagnostic name of the handler is used to distinguish logs in traces coming from a subscription per individual handler.
+
+Normally Eventuous uses either the `BaseEventHandler` abstract base class. For specific implementations, you'd either use a built-in handler provided by a projection (like MongoDB projection), or the `EventHandler` abstract base class.
+
+### Consume context
+
+The subscription will invoke all its event handlers at once for each event received. Instead of just getting the event, the handler will get an instance of the message context (`IMessageConsumeContext` interface). The context contains the payload (event or other message) in its `Message` property, which has the type `object?`. It's possible to handle each event type differently by using pattern matching:
+
+```csharp
+public ValueTask<EventHandlingStatus> HandleEvent(IMessageConsumeContext ctx) {
+    return ctx.Message switch {
+        V1.RoomBooked => ...
+        _ => EventHandlingStatus.Ignored
+    };
+}
+```
+
+However, it's easier and more explicit to use pre-optimised base handlers. For read model projections you can use [Projections] handlers, described separately. For integration purposes you might want to use the [Gateway](../../gateway). For more generic needs, Eventuous offers the `EventHandler` base class. It allows specifying typed handlers for each of the event types that the handler processes:
+
+```csharp
+public class MyHandler : EventHandler {
+    public MyHandler(SmsService smsService) {
+        On<RoomBooked>(async ctx => await smsService.Send($"Room {ctx.Message.RoomId} booked!"));
+    } 
+}
+```
+
+The typed handler will get an instance of `MessageConsumeContext<T>` where `T` is the message type. There, you can access the message using the `Message` property without casting it.
+
+A subscription will invoke a single consumer and give it an instance of the consume context. The consumer's job is to handle the message by invoking all the registered handlers. By default, Eventuous uses the `DefaultConsumer`, unless specified otherwise when registering the subscription. The `IMessageConsumeContext` interface has functions to acknowledge (ACK), not acknowledge (NACK), or ignore the message. The default consumer ACKs the message when all the handlers processed the message without failures, and at least one handler didn't ignore the message. It NACKs the message if any handler returned an error or crashed. Finally, it will ignore the message if all the handlers ignored it. How the message handling result is processed is unknown to the consumer as this behaviour is transport-specific. Each subscription type has its own way to process the message handling result.
+
+### Handling result
+
+The handler needs to return the handling status. It's preferred to return the error status `EventHandlingStatus.Failure` instead of throwing an exception. When using the `EventHandler` base class, if the event handling function throws an exception, the handler will return the failure status and not float the exception back to the subscription.
+
+The status is important for diagnostic purposes. For example, you don't want to trace event handlers for events that are ignored. That's why when you don't want to process the event, you need to return `EventHandlingStatus.Ignored`. The `EventHandler` base class will do it automatically if it gets an event that has no registered handler.
+
+When the event is handled successfully (neither failed nor ignored), the handler needs to return `EventHandlingStatus.Success`. Again, the `EventHandler` base class will do it automatically if the registered handler doesn't throw.
+
+The subscription will acknowledge the event only if all of its handlers _don't fail_. How subscriptions handle failures depends on the transport type.
+
+## Registration
+
+As mentioned before, you'd normally register subscriptions using the DI extensions provided by Eventuous. This example uses the [EventStoreDB](../../infra/esdb) subscription.
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<StreamSubscription, StreamSubscriptionOptions>(
+    "PaymentIntegration",
+    builder => builder
+        .Configure(x => x.StreamName = PaymentsIntegrationHandler.Stream)
+        .AddEventHandler<PaymentsIntegrationHandler>()
+);
+```
+
+The `AddSubscription` extension needs two generic arguments: subscription implementation and its options. Every implementation has its own options as the options configure the particular subscription transport.
+
+The first parameter for `AddSubscription` is the subscription name. It must be unique within the application scope. Eventuous uses the subscription name to separate one subscription from another, along with their options and other things. The subscription name is also used in diagnostics as a tag.
+
+Then, you need to specify how the subscription builds. There are two most used functions in the builder:
+
+- `Configure`: allows to change the subscription options
+- `AddEventHandler<T>`: adds an event handler to the subscription
+
+You can add several handlers to the subscription, and they will always "move" together throw the events stream or topic. If any of the handlers fail, the subscription might fail, so it's "all or nothing" strategy.
+
+Eventuous uses the consume pipe, where it's possible to add filters (similar to [MassTransit](http://masstransit-project.com)). You won't need to think about it in most of the cases, but you can read mode in the [Pipes and filters](../pipes) section.
+
+## Subscription drops
+
+A subscription could drop for different reasons. For example, it fails to pass the keep alive ping to the server due to a transient network failure, or it gets overloaded.
+
+The subscription service handles such drops and issues a resubscribe request, unless the application is shutting down, so the drop is deliberate.
+
+This feature makes the subscription service resilient to transient failures, so it will recover from drops and continue processing events, when possible.
+
+You can configure the subscription to ignore failures and continue by setting `ThrowIfError` property of `SubscriptionOptions` to `false`.
+
diff --git a/docs/src/content/docs/0.15/subscriptions/subs-concept.mdx b/docs/src/content/docs/0.15/subscriptions/subs-concept.mdx
new file mode 100644
index 000000000..8fb472175
--- /dev/null
+++ b/docs/src/content/docs/0.15/subscriptions/subs-concept.mdx
@@ -0,0 +1,79 @@
+---
+title: "Real-time subscription"
+description: "The concept of real-time subscriptions"
+sidebar:
+  order: 1
+---
+import ThemedImage from '@components/ThemedImage.astro';
+import subscriptions from './images/subscriptions.png';
+import subscriptionsDark from './images/subscriptions-dark.png';
+
+Real-time subscriptions are essential when building a successful event-sourced system. They support the following sequence of operations:
+
+- Domain model emits new event
+- The event is stored to the event store
+- The command is now handled, and the transaction is complete
+- All the [read models](../../read-models/rm-concept) get the new event _from the store_ and project it if necessary
+
+Most of the time, subscriptions are used for two purposes:
+1. Deliver events to reporting models
+2. Emit integration events
+
+Subscriptions can subscribe from any position of a stream, but normally you'd subscribe from the beginning of the stream, which allows you to process all the historical events. For integration purposes, however, you would usually subscribe from _now_, as emitting historical events to other systems might produce undesired side effects.
+
+One subscription can serve multiple event handlers. Normally, you would identify a group of event handlers, which need to be triggered together, and group them within one subscription. This way you avoid situations when, for example, two real models get updated at different speed and show confusing information if those read models are shown on the same screen.
+
+:::caution
+**Example (real life horror story)**
+
+Imagine an event stream, which contains positions of a car as well as the car state changes, like `Parked`, `Moving` or `Idle`. The system also has two independent subscriptions serve two read model projections - one is the last know car location, and the other one is the car state. Those subscriptions will, with great probability, come out of sync, simply because position events are much more frequent than state updates. When using both of those read models on the map, you easily get a situation when the car pointer is _moving_, whilst the car is shown as _parked_.
+
+By combining those two projections in _one subscription_, they could be both behind with updates, but the user experience will be much better as it will never be confusing. We could also say that those two projections belong to the same _projections group_.
+:::
+
+Subscriptions need to maintain their own [checkpoints](../checkpoint), so when the service that host a subscription restarts, it will start receiving events from the last known position in the stream.
+
+Most often, you'd want to subscribe to the _global event stream_, so you can build read models, which compose information from different aggregates. Eventuous offers the [All stream subscription](../../infra/esdb/#all-stream-subscription) for this use case. In some cases you'd need to subscribe to a regular stream using the [stream subscription](../../infra/esdb/#single-stream-subscription).
+
+In Eventuous, subscriptions are specific to event store implementation. In addition, Eventuous has subscriptions to message brokers like Google PubSub and RabbitMQ for integration purposes.
+
+## The wrong way
+
+One of the common mistakes people make when building an event-sourced application is using an event store which is not capable of handling realtime subscriptions. It forces developers to engage some sort of message bus to deliver new events to subscribers. There are [quite a few issues](../../prologue/the-right-way) with that approach, but the most obvious one is a two-phase commit.
+
+:::tip[Bad bus]
+Read more about the **[Bad Bus →](../../prologue/the-right-way/#event-bus)**
+:::
+
+When using two distinct pieces of infrastructure in one transaction, you risk one of those operations to fail. Let's use the following example code, which is very common:
+
+```csharp
+await _repository.Save(newEvents);
+await _bus.Publish(newEvents);
+```
+
+If the second operation fails, the command side of the application would remain consistent. However, any read models, which projects those events, will not be updated. So, essentially, the reporting model will become inconsistent against the transactional model. The worst part is that the reporting model will never recover from the failure.
+
+As mentioned, there are multiple issues of using a message bus as transport to deliver events to reporting models, but we won't be covering them on this page.
+
+The easiest way to solve the issue is to use a database which supports realtime subscriptions to event streams out of the box. That's why we use EventStoreDB as the primary event store implementation.
+
+## The right way
+
+It is not hard to avoid the two-phase commits and ensure to publish domain events reliably if you use a proper event store. The aim here would be to achieve the following architecture:
+
+<ThemedImage
+    alt="Consistent event flow"
+    lightSrc={subscriptions}
+    darkSrc={subscriptionsDark}
+/>
+
+Why is this flow "consistent"? It's because the command handling process always finishes with an append operation towards event store (unless the command fails). There's no explicit `Publish` or `Produce` call that happens after the event is persisted. A proper event store should have a capability for to subscribe for getting all the new events when they appear in the store. As the `Append` operation of the event store is transactional, such a subscription will get the event only once, if it is capable to acknowledge the event correctly back to the subscription.
+
+Subscriptions have many purposes. Most often, you would use a subscription to project domain events to your query models ([read models](../../read-models/rm-concept)). You can also use subscriptions to transform and publish integration events (see [Gateway](../../gateway)).
+
+Subscriptions can also be used for integration purposes in combination with [Producers](../../producers).
+
+## Implementation
+
+Eventuous implement subscriptions for different kinds of infrastructure (transport). As each transport is different, the way to configure them can be different, as well as the way subscriptions work. Read carefully the [guidelines](../../infra/esdb) for each transport to understand what transport to use for your use case.
diff --git a/docs/src/content/docs/0.15/subscriptions/subs-diagnostics.md b/docs/src/content/docs/0.15/subscriptions/subs-diagnostics.md
new file mode 100644
index 000000000..936fd9e1e
--- /dev/null
+++ b/docs/src/content/docs/0.15/subscriptions/subs-diagnostics.md
@@ -0,0 +1,108 @@
+---
+title: "Diagnostics"
+description: "Monitoring subscriptions"
+---
+
+Out of the box, Eventuous provides metrics and traces for monitoring your subscriptions.
+
+Also, study the [Diagnostics](../../diagnostics) section for more information.
+
+## Mind the gap
+
+When using subscriptions for read model projections, you enter to the world of [CQRS](https://zimarev.com/blog/event-sourcing/cqrs/) and asynchronous messaging. After completing a transaction in the domain model, one or more events are added to the event store. Then, a subscription picks it up and calls a projection. Although in most cases you'll see only a few milliseconds delay between these operations, if your projection becomes slow (for example, it uses a slow database), the processing time will increase.
+
+The easiest way to detect such situations is to observe the gap between the last event in the stream, which the subscription listens to, and the event, which is currently being processed. We call it the **subscription gap**.
+
+:::caution[Alerting for the gap]
+If the gap increases continuously, your subscription is not catching up with all the events it receives. You need to set up a proper metric for the gap, and trigger an alert if the gap exceeds the value you can tolerate.
+:::
+
+The gap is measured by subscriptions that implement the `IMeasuredSubscription` interface:
+
+```csharp
+public interface IMeasuredSubscription {
+    GetSubscriptionGap GetMeasure();
+}
+```
+
+Subscription gaps are collected as metrics. Read more about Eventuous subscription metrics below.
+
+## Subscription metrics
+
+Eventuous collects two types of metrics for subscriptions:
+- Subscription gap in time and count
+- Subscription performance
+
+For the subscription gap, Eventuous collects the time and count of the gap between the last event in the stream, which the subscription listens to, and the event, which is currently being processed.
+
+Keep in mind that due to the limitation of EventStoreDB, the gap event count is not accurate when subscribing to `$all` stream. It's because the `$all` stream position is the commit position of the event in the global log, not the position of the event in the stream. Unfortunately, as per today, it is impossible to translate the commit position gap to the number of events.
+
+Here is an example of the subscription gap metric exported to Prometheus:
+
+```txt
+# HELP eventuous_subscription_gap_count_events Gap between the last processed event and the stream tail
+# TYPE eventuous_subscription_gap_count_events gauge
+eventuous_subscription_gap_count_events{subscription_id="BookingsProjections"} 1098 1649081749067
+eventuous_subscription_gap_count_events{subscription_id="PaymentIntegration"} 0 1649081749067
+```
+
+In addition to the subscription gap metric, Eventuous also collects metrics for the subscription performance as a histogram. The metric name is `eventuous_subscription_duration`. It measures the duration of handling a single event. As handling different event types might trigger different kinds of processing, the histogram is tagged with the message type (`message_type` tag).
+
+All the subscription metrics are tagged by the subscription id (`subscription_id` tag). It allows you to plot a graph of the subscription metrics for different subscriptions.
+
+Here is an example of the subscription duration metrics exported as a Prometheus [metric](https://prometheus.io/docs/practices/naming/) for the subscription with id `BookingsProjections`:
+
+```txt
+# HELP eventuous_subscription_duration_ms Processing duration, milliseconds
+# TYPE eventuous_subscription_duration_ms histogram
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="0"} 0 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="5"} 0 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="10"} 0 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="25"} 0 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="50"} 0 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="75"} 1 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="100"} 1 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="250"} 1 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="500"} 1 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="1000"} 1 1649081749067
+eventuous_subscription_duration_ms_bucket{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections",le="+Inf"} 1 1649081749067
+eventuous_subscription_duration_ms_sum{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections"} 50.429 1649081749067
+eventuous_subscription_duration_ms_count{message_type="V1.RoomBooked",partition="0",subscription_id="BookingsProjections"} 1 1649081749067
+```
+
+## Subscription tracing
+
+Each part of the subscription event processing [pipeline](../pipes) is traced. Each event is wrapped into a consume context by the subscription, then passed to the consumer. The consumer then calls all the event handlers.
+
+```mermaid
+graph LR;
+    Subscription --> Consumer
+    Consumer --> B1[Handler 1]
+    Consumer --> B2[Handler 2]
+    Consumer --> B3[Handler 3]
+```
+
+As all Eventuous producers and event store(s) are instrumented, they propagate the trace context to the subscription. The subscription then propagates the trace context to the consumer, and the consumer then propagates the trace context to the event handlers, so all these operations are traced.
+
+Here's an example of the trace context propagated to the subscription visualized by Zipkin:
+
+![Subscription trace](./images/sub-trace.png)
+
+As you can see, event handlers for the `BookingProjection` subscription are projections, and trigger updates in MongoDB, which are also traced because the sample application is instrumented by MongoDB tracing library.
+
+As mentioned before, Eventuous ensures that the tracing context is propagated also remotely, so you get the full trace even if the subscription is running in a different process.
+
+## Health checks
+
+The subscription service class also implements the `IHealthCheck` interface. Therefore, it can be used for [ASP.NET Core health monitoring](https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-5.0).
+
+When using Eventuous dependency injection extensions, each registered subscription will also register its health checks.
+
+However, you need to register the global Eventuous subscriptions health check by adding one line to the ASP.NET Core health checks registration:
+
+```csharp title="Program.cs"
+builder.Services
+    .AddHealthChecks()
+    .AddSubscriptionsHealthCheck("subscriptions", HealthStatus.Unhealthy, new []{"tag"});
+```
+
diff --git a/docs/src/content/docs/0.15/whats-new.mdx b/docs/src/content/docs/0.15/whats-new.mdx
new file mode 100644
index 000000000..386fe929a
--- /dev/null
+++ b/docs/src/content/docs/0.15/whats-new.mdx
@@ -0,0 +1,141 @@
+---
+title: "What's new in 0.15"
+sidebar:
+  order: 2
+---
+
+Eventuous v0.15 includes a number of changes and bug fixes, where some of the previous version public APIs are deprecated. Where possible, we made those APIs obsolete and embedded polyfills to make them work, but some APIs are gone for good as it wasn't possible to translate the old API to the new one. Those changes are listed below.
+
+## Breaking changes
+
+### .NET SDK targets
+
+Eventuous 0.15 adds support for .NET 8 and removes support for .NET 7. Currently supported SDKs are .NET 6 and .NET 8.
+
+### Packages
+
+* `Eventuous.AspNetCore` is renamed to `Eventuous.Extensions.DependencyInjection`.
+* `Eventuous.AspNetCore.Web` is renamed to `Eventuous.Extensions.AspNetCore`.
+
+### Domain abstractions
+
+* Aggregate base type without state is removed. The only remaining abstraction is `Aggregate<TState>`. Removal of non-generic `Aggregate` base class triggered a chain of changes for command services and registrations.
+* Aggregate factory extensions require specifying `TState` now. So, use `AddAggregate<T, TState>` instead of `AddAggregate<T>`.
+
+### Persistence
+
+* Aggregate store is no longer used by command services. Its interface, implementation, and registration extensions are marked obsolete. You can still use it outside command services but the whole thing might be removed in the future.
+* `IEventStore` got extensions to work with aggregates, which allowed to avoid using `IAggregateStore`.
+* `IEventWriter.AppendEvents` now needs a collection of `NewStreamEvents` instead of `StreamEvent` as the `StreamEvent` struct has properties that are irrelevant for new events (position, content type, etc).
+
+### Command services
+
+* Non-generic `ICommandService` interface is removed.
+* `IStateCommandService<TState>` is replaced by `ICommandService<TState>`. Both aggregate-based and functional command services implement that interface.
+* Command services no longer use `IAggregateStore`, so it doesn't need to be registered in the DI container. Replace `AddAggregateStore` by `AddEventStore`.
+* Non-generic `Result`, `OkResult` and `ErrorResult` types are removed. Only generic `Result<TState>` is supported. Read more [here](../application/app-service#result).
+* Service registration extension replaced by `AddCommandService<TService, TState>`:
+    * `AddCommandService<TService, TAggregate>`
+    * `AddCommandService<TService, TAggtegate, TId>`
+    * `AddFunctionalService<TState>`
+* Command service metrics are renamed to:
+    * `eventuous_service_duration` for command duration
+    * `eventuous_service_error_count` for command errors
+
+### HTTP API extensions
+
+* Controller base class requires `TState` generic argument instead of `TAggregate`, so the new definition is `CommandHttpApiBase<TState>`. Therefore, it can be used with both aggregate-based and functional command services. It takes `ICommandService<TState>` as a dependency.
+* `CommandHttpApiBaseFunc` base class is removed because it's no longer required. Use `CommandHttpApiBase<TState>` instead.
+* Controller methods need to return `ActionResult<Result<TState>.Ok>`.
+* `MessageMap` optional dependency for controllers is replaced by `CommandMap<HttpContext>`, so it's now possible to populate additional command properties from the HTTP context.
+* `AggregateCommands<TAggregate>` attribute is gone, use `HttpCommands<TState>` instead. It supports both aggregate-based and functional services.
+* `HttpCommand<TAggregate>` attribute is gone, use `HttpCommand<TState>` instead. It supports both aggregate-based and functional services.
+* `MapAggregateCommands<TAggregate>` is replaced with `MapCommands<TState>`.
+* `MapDiscoveredCommands<TAggregate>` is replaced with `MapDiscoveredCommands<TState>`.
+* `MapCommand<TAggregate, TCommand>` is replaced by `MapCommand<TState, TCommand>`.
+* `MapCommand<TAggregate, TCommand, TResult>` is gone as custom results aren't supported in command mapping. Use `MapCommand<TState, TCommand>` and `Result<TState>` instead.
+* The same applies to command mappings with external-internal command conversion. Aggregate constraint is replaced by state type constraint, and a custom result type is no longer supported in favour of `Result<TState>`.
+
+:::note
+Current APIs for working with HTTP is [documented here](../application/command-api).
+:::
+
+### Subscriptions
+
+Subscriptions are now being registered in the DI container using keyed dependencies. It requires to use `Microsoft.Extensions.DependencyInjection` version 8 and higher. If you use ASP.NET Core DI container in combination with another container like Autofac, make sure you use the version that supports keyed registrations in ASP.NET Core services collection.
+
+Subscriptions also got `IEventSerializer` (all of them) and `IMetadataSerializer` (EventStoreDB, Postgres and SQL Server) as dependencies, and subscription option properties holding those are removed. The reason is that serializers can now play nicely with dependency injection, which is particularly relevant to event serializers as they depend on `TypeMapper`. It is now easier to use separated type maps. One case for that is Eventuous tests where the global type map created issues with conflicting type registrations.
+
+### Producers
+
+* `IEventProducer` was already marked obsolete, and it's now gone. the `IProducer` interface is 100% compatible, so you can need to rename the usages.
+* Producers without options are no longer supported.
+
+### Postgres
+
+* Postgres store options now include connection string, schema name and initialize properties.
+* Postgres store now uses `NpgsqlDataSource`.
+* Calling `AddEventuousPostgres` registers `NpgsqlDataSource` in the container using the provided options.
+* Loading `PostgresStoreOptions` from the configuration is now supported.
+* Postgres subscriptions use `NpgsqlDataSource` as well, but registering a subscription doesn't add the data source as subscription options don't have the connection string. You can either register the data source manually using `Npgsql` own extensions, or use `AddEventuousPostgres`.
+
+### SQL Server
+
+* SQL Server store options now include connection string, schema name and initialize properties.
+* Calling `AddEventuousSqlServer` registers the connection factory, which then is used by the store.
+* SQL Server subscription options class also has the connection string property, so if your service only implements subscriptions, you don't need to call `AddEventuousSqlServer`. However, subscriptions don't initialize the schema.
+
+## New things
+
+There are many small improvements in 0.15, here you can find the list of most important improvements.
+
+### Services
+
+As it becomes clear from breaking changes, Eventuous doesn't distinct aggregate-based and functional services when services are being used in public APIs. Both service flavours now implement a single interface `ICommandService<TState>`, which greatly simplified all downstream APIs like command-handling controllers and minimal API command handlers. You can now decide to move from one flavour to another and only reimplement the service itself without changing the rest of the application.
+
+Command services how can resolve the store based on command payload. It can be useful, for example, in multitenant environments where the command contains information about the tenant, so you can resolve a different store for each tenant for data isolation.
+
+### Gateways
+
+Using keyed dependencies for registering subscription allows using the same event handler for multiple subscriptions. It is also supported in gateways. Previously, multiple gateways would reuse the same transformation function or class, even if you explicitly provide different implementations for different gateways. Not every gateway registration is able to distinct transformations between them, so use one of those:
+
+```csharp
+AddGateway<TSubscription, TSubscriptionOptions, TProducer, TProduceOptions, TTransform>()
+```
+
+```csharp
+AddGateway<TSubscription, TSubscriptionOptions, TProducer, TProduceOptions>(
+    string                             subscriptionId,
+    RouteAndTransform<TProduceOptions> routeAndTransform
+)
+```
+
+### Relational databases
+
+Both Postgres and SQL Server libraries now use the same base implementation. It's now possible to add support for other relational databases using the same abstraction, if someone is willing to experiment or contribute.
+
+Both Postgres and SQL Server libraries got simple projector implementations as well as checkpoint stores.
+
+TODO: Add docs links
+
+Postgres library supports Postgres 7+ with the latest version of `Npgsql` and uses `NpgsqlDataSource`.
+
+All RDBMS-based subscriptions use frequent polling with backpressure. It means that when the polling query doesn't return new events, the subscription will start increasing the polling interval. It allows decreasing the number of empty queries to the database when the system is not under load.
+
+Check the relevant RDBMS-based implementation documentation for more details.
+
+Subscriptions now provide lag metrics and health checks.
+
+Subscriptions now handle transient errors and support retries. Each RDBMS-based implementation has its own logic for that.
+
+### MongoDB
+
+MongoDB projections now support bulk operations.
+
+### Redis
+
+Experimental support for Redis event store and subscriptions added as a separate package.
+
+### Testing
+
+A simple testing library `Eventuous.Testing` now allows creating test specs for aggregates. Eventuous uses it internally in tests.
diff --git a/docs/src/content/docs/application/app-service.md b/docs/src/content/docs/application/app-service.md
new file mode 100644
index 000000000..1993d7b36
--- /dev/null
+++ b/docs/src/content/docs/application/app-service.md
@@ -0,0 +1,131 @@
+---
+title: "Command service"
+description: "Command service and unit of work for aggregates"
+sidebar:
+  order: 10
+---
+
+## Concept
+
+The command service itself performs the following operations when handling one command:
+1. Extract the aggregate id from the command, if necessary.
+2. Instantiate all the necessary value objects. This could effectively reject the command if value objects cannot be constructed. The command service could also load some other aggregates, or any other information, which is needed to execute the command but won't change state.
+3. If the command expects to operate on an existing aggregate instance, this instance gets loaded from the [Aggregate Store](../../persistence/aggregate-store).
+4. Execute an operation on the loaded (or new) aggregate, using values from the command, and the constructed value objects.
+5. The aggregate either performs the operation and changes its state by producing new events, or rejects the operation.
+6. If the operation was successful, the service persists new events to the store. Otherwise, it returns a failure to the edge.
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant API Endpoint
+    participant Command Service
+    participant Aggregate
+    participant Aggregate Store
+
+    Client->>+API Endpoint: Request
+    API Endpoint->>API Endpoint: Deserialize request
+    API Endpoint->>+Command Service: Command
+    Command Service->>+Aggregate Store: Load
+    Aggregate Store-->>-Command Service: Aggregate
+    Command Service->>+Aggregate: Execute
+    Aggregate-->>-Command Service: Updated aggregate
+    Command Service->>+Aggregate Store: Store changes
+    Aggregate Store-->>-Command Service: Return result
+    Command Service-->>-API Endpoint: Return result
+    API Endpoint-->>-Client: Return result
+```
+
+:::caution[Handling failures]
+The last point above translates to: the command service **does not throw exceptions**. It [returns](#result) an instance of `ErrorResult` instead. It is your responsibility to handle the error.
+:::
+
+## Implementation
+
+Eventuous provides a base class for you to build command services. It is a generic abstract class, which is typed to the aggregate type. You should create your own implementation of a command service for each aggregate type. As command execution is transactional, it can only operate on a single aggregate instance, and, logically, only one aggregate type.
+
+### Handling commands
+
+The base class has one function that must be used in the service class constructor to define how the service will handle commands. The function is called `On<TCommand>` where `TCommand` is the command type. You can add as many command handlers as you need. The `On` function composes a command handler builder that allows to chain further details to describe how the command needs to be processed.
+
+After calling `On`, add two more calls to the builder:
+* `InState(ExpectedState)` to specify what is the expected aggregate state is. For example, if the `BookRoom` command expects that no booking exists with a given identity, you'd specify `InState(ExpectedState.New)`. There are three possible states: `New`, `Existing`, and `Any`.
+* `GetId(Func<TCommand, TId>)` to explain the service how to use one or more properties of `TCommand` type to compose an identity object for loading and storing the aggregate state.
+
+After that, use one of the `Act` functions to specify the business logic of the command handler. There are two available functions for it: `Act` and `ActAsync`.
+
+Here is an example of a command service form our test project:
+
+```csharp title="BookingService.cs"
+public class BookingsCommandService 
+    : CommandService<Booking, BookingState, BookingId> {
+    public BookingsCommandService(
+        IAggregateStore store, 
+        Services.IsRoomAvailable isRoomAvailable
+    ) : base(store) {
+        On<BookRoom>()
+            .InState(ExpectedState.New)
+            .GetId(cmd => new BookingId(cmd.BookingId))
+            .ActAsync(
+                (booking, cmd, _) => {
+                    var period = new StayPeriod(
+                        LocalDate.FromDateTime(cmd.CheckInDate), 
+                        LocalDate.FromDateTime(cmd.CheckOutDate)
+                    ),
+                    booking.BookRoom(
+                        cmd.GuestId,
+                        new RoomId(cmd.RoomId),
+                        stayPeriod,
+                        new Money(cmd.BookingPrice, cmd.Currency),
+                        new Money(cmd.PrepaidAmount, cmd.Currency),
+                        DateTimeOffset.Now,
+                        isRoomAvailable
+                    );
+                }
+            );
+
+        On<RecordPayment>()
+            .InState(ExpectedState.Existing)
+            .GetId(cmd => new BookingId(cmd.BookingId))
+            .Act((booking, cmd) => 
+                booking.RecordPayment(
+                    new Money(cmd.PaidAmount, cmd.Currency), 
+                    cmd.PaymentId, 
+                    cmd.PaidBy, 
+                    DateTimeOffset.Now
+                ));
+    }
+}
+```
+
+:::caution[Stream name]
+Check the [stream name](../../persistence/aggregate-stream#stream-name) documentation if you need to use custom stream names.
+:::
+
+### Result
+
+The command service will return an instance of `Result<TState>`.
+
+It could be an `OkResult<TState>`, which contains the new aggregate state and the list of new events. You use the data in the result to pass it over to the caller, if needed.
+
+If the operation was not successful, the command service will return an instance of `ErrorResult` that contains the error message and the exception details.
+
+### Bootstrap
+
+If you registered the `KurrentDBEventStore` and the `AggregateStore` in your `Startup` as described on the [Aggregate store](../../persistence/aggregate-store) page, you can also register the command service:
+
+```csharp title="Program.cs"
+builder.Services.AddCommandService<BookingCommandService, BookingState>();
+```
+
+The `AddCommandService` extension will register the `BookingService`, and also as `ICommandService<BookingState>`, as a singleton. Remember that all the DI extensions are part of the `Eventuous.Extensions.DependencyInjection` NuGet package.
+
+When you also use `AddControllers`, you get the command service injected to your controllers.
+
+You can simplify your application and avoid creating HTTP endpoints explicitly (as controllers or minimal API endpoints) if you use the [command API feature](../command-api).
+
+## Application HTTP API
+
+The most common use case is to connect the command service to an HTTP API.
+
+Read the [Command API](../command-api) feature documentation for more details.
diff --git a/docs/src/content/docs/application/command-api.md b/docs/src/content/docs/application/command-api.md
index 7c2f2c82f..65842c463 100644
--- a/docs/src/content/docs/application/command-api.md
+++ b/docs/src/content/docs/application/command-api.md
@@ -1,19 +1,36 @@
 ---
-title: "Using services in HTTP API"
+title: "Command API"
 description: "Auto-generated HTTP API for command handling"
 sidebar:
-  order: 3
+  order: 30
 ---
 
-:::note
-Install `Eventuous.Extensions.AspNetCore` package for using Eventuous HTTP API support.
-:::
-
 ## Controller base
 
-Eventuous allows you to simplify the command handling in the API controller by using a `CommandHttpApiBase<TState>` abstract class, which implements
-the `ControllerBase` and contains the `Handle` method. The class takes `ICommandService<TState>` as a dependency. The `Handle` method will call the command
-service, and also convert the handling result to `ActionResult<Result<TState>.Ok>`. Here are the rules for exception handling:
+When using a command service from an HTTP controller, you'd usually inject the service as a dependency, and call it's `Handle` method using the request body:
+
+```csharp title="Api/BookingCommandApi.cs"
+[Route("/booking")]
+public class CommandApi : ControllerBase {
+    ICommandService<Booking> _service;
+
+    public CommandApi(ICommandService<Booking> service) => _service = service;
+
+    [HttpPost]
+    [Route("book")]
+    public async Task<ActionResult<Result>> BookRoom(
+        [FromBody] BookRoom cmd, 
+        CancellationToken cancellationToken
+    ) {
+        var result = await _service.Handle(cmd, cancellationToken);
+        result Ok(result);
+    }
+}
+```
+
+The issue here is there's no way to know if the command was successful or not. As the command service won't throw an exception if the command fails, we can't return an error via the HTTP response, unless we parse the [result](../app-service#result) and return a meaningful HTTP response.
+
+Eventuous allows you to simplify the command handling in the API controller by providing a `CommandHttpApiBase<TAggregate>` abstract class, which implements the `ControllerBase` and contains the `Handle` method. The class takes `ICommandService<TAggregate>` as a dependency. The `Handle` method will call the command service, and also convert the handling result to `ActionResult<Result>`. Here are the rules for exception handling:
 
 | Result exception                 | HTTP response |
 |----------------------------------|---------------|
@@ -25,87 +42,70 @@ Here is an example of a command API controller:
 
 ```csharp
 [Route("/booking")]
-public class CommandApi(ICommandService<BookingState> service) 
-    : CommandHttpApiBase<BookingState> {
+public class CommandApi : CommandHttpApiBase<Booking> {
+    public CommandApi(ICommandService<Booking> service) : base(service) { }
+
     [HttpPost]
     [Route("book")]
-    public Task<ActionResult<Result<BookingState>.Ok>> BookRoom(
+    public Task<ActionResult<Result>> BookRoom(
         [FromBody] BookRoom cmd, 
         CancellationToken cancellationToken
     ) => Handle(cmd, cancellationToken);
 }
 ```
 
-Although the controller endpoint method returns `ActionResult<Result<TState>.Ok>`, it does that only if the command was handled successfully. If the command
-service was unable to process the command, it will generate an instance of:
-
-* `ProblemDetails` with status code `404` if there's no stream to operate on
-* `ProblemDetails` with status code `409` in case of optimistic concurrency issues
-* `ValidationProblemDetails` with `400` status code in case there was a domain exception
-* `ProblemDetails` with status code `500` for any other issue
+We recommend using the `CommandHttpApiBase` class when you want to handle commands using the HTTP API.
 
-For making those responses available in the OpenAPI generated documentation, you'd need to annotate your controller methods accordingly. Eventuous provides
-several attributes to help with that, as well as an attribute to specify the success return type if your controller endpoint returns `IActionResult`:
+When using [functional services](../func-service) you can use the `CommandHttpApiBaseFunc` base class, which works exactly the same way:
 
 ```csharp
-public class BookingApi(ICommandService<BookingState> service)
-    : CommandHttpApiBase<BookingState>(service) {
-    [HttpPost("v2/pay")]
-    [ProducesResult<BookingState>]
-    [ProducesConflict]
-    [ProducesDomainError]
-    [ProducesNotFound]
-    public async Task<IActionResult?> RegisterPayment(
-        [FromBody] RegisterPaymentHttp cmd, 
-        CancellationToken cancellationToken
-    ) {
-        var result = await Handle(cmd, cancellationToken);
+[Route("/booking")]
+public class CommandApi : CommandHttpApiBaseFunc<Booking> {
+    public CommandApi(IFuncCommandService<Booking> service) : base(service) { }
 
-        return result.Result;
-    }
+    [HttpPost]
+    [Route("book")]
+    public Task<ActionResult<Result>> BookRoom(
+        [FromBody] BookRoom cmd, 
+        CancellationToken cancellationToken
+    ) => Handle(cmd, cancellationToken);
 }
 ```
 
 ## Generated command API
 
-Eventuous can use your command service to generate a command API. Such an API will accept JSON models matching the application service command contracts, and
-pass those commands as-is to the application service. This feature removes the need to create API endpoints manually using controllers or .NET minimal API.
+Eventuous can use your command service to generate a command API. Such an API will accept JSON models matching the application service command contracts, and pass those commands as-is to the application service. This feature removes the need to create API endpoints manually using controllers or .NET minimal API. 
+
+To use generated APIs, you need to add `Eventuous.AspNetCore.Web` package.
 
 All the auto-generated API endpoints will use the `POST` HTTP method.
 
 ### Annotating commands
 
-For Eventuous to understand what commands need to be exposed as API endpoints and on what routes, those commands need to be annotated by the `HttpCommand`
-attribute:
+For Eventuous to understand what commands need to be exposed as API endpoints and on what routes, those commands need to be annotated by the `HttpCommand` attribute:
 
 ```csharp
-[HttpCommand<BookingState>(Route = "payment")]
+[HttpCommand<Booking>(Route = "payment")]
 public record ProcessPayment(string BookingId, float PaidAmount);
 ```
 
-Eventuous will then map the command to an HTTP `POST` endpoint that will resolve an instance of `ICommandService<BookingState>` which can be either a
-aggregate-based command service or a functional service, and pass the command to it.
+You can skip the `Route` property, in that case Eventuous will use the command class name. For the example above the generated route would be `processPayment`. We recommend specifying the route explicitly as you might refactor the command class and give it a different name, and it will break your API if the route is auto-generated.
 
-You can skip the `Route` property, in that case Eventuous will use the command class name. For the example above the generated route would be `processPayment`.
-We recommend specifying the route explicitly as you might refactor the command class and give it a different name, and it will break your API if the route is
-auto-generated.
+If your application has a single command service working with a single aggregate type, you don't need to specify the aggregate type, and then use a different command registration method (described below).
 
-If your application has a single command service working with a single state type, you don't need to specify the state type, and then use a different command
-registration method (described below).
-
-Another way to specify the state type for a group of commands is to annotate the parent class (command container):
+Another way to specify the aggregate type for a group of commands is to annotate the parent class (command container):
 
 ```csharp
-[StateCommands<BookingState>()]
+[AggregateCommands<Booking>()]
 public static class BookingCommands {
     [HttpCommand(Route = "payment")]
     public record ProcessPayment(string BookingId, float PaidAmount);
 }
 ```
 
-In such case, Eventuous will treat all the commands defined inside the `BookingCommands` static class as commands operating on `BookingState`.
+In such case, Eventuous will treat all the commands defined inside the `BookingCommands` static class as commands operating on the `Booking` aggregate.
 
-Also, you don't need to specify the state type in the command annotation if you use the `MapCommands` registration (see below).
+Also, you don't need to specify the aggregate type in the command annotation if you use the `MapAggregateCommands` registration (see below).
 
 Finally, you don't need to annotate the command at all if you use the explicit command registration with the route parameter.
 
@@ -121,12 +121,12 @@ The simplest way to register a single command is to make it explicitly in the bo
 var builder = WebApplication.CreateBuilder();
 
 // Register the app service
-builder.Services.AddCommandService<BookingService, BookingState>();
+builder.Services.AddCommandService<BookingService, Booking>();
 
 var app = builder.Build();
 
 // Map the command to an API endpoint
-app.MapCommand<ProcessPayment, BookingState>("payment");
+app.MapCommand<ProcessPayment, Booking>("payment");
 
 app.Run();
 
@@ -136,7 +136,7 @@ record ProcessPayment(string BookingId, float PaidAmount);
 If you annotate the command with the `HttpCommand` attribute, and specify the route, you can avoid providing the route when registering the command:
 
 ```csharp
-app.MapCommand<ProcessPayment, BookingState>();
+app.MapCommand<BookingCommand, Booking>();
 
 ...
 
@@ -144,14 +144,13 @@ app.MapCommand<ProcessPayment, BookingState>();
 public record ProcessPayment(string BookingId, float PaidAmount);
 ```
 
-#### Multiple commands for one service
+#### Multiple commands for an aggregate
 
-You can also register multiple commands for the same service type without a need to provide the state type in the command annotation. To do that, use the
-extension that will create an `CommandServiceRouteBuilder`, then register commands using that builder:
+You can also register multiple commands for the same aggregate type, without a need to provide the aggregate type in the command annotation. To do that, use the extension that will create an `CommandServiceRouteBuilder`, then register commands using that builder:
 
 ```csharp
 app
-    .MapCommands<BookingState>()
+    .MapAggregateCommands<Booking>()
     .MapCommand<ProcessPayment>()
     .MapCommand<ApplyDiscount>("discount");
 
@@ -169,10 +168,10 @@ public record ApplyDiscount(string BookingId, float Discount);
 
 There are two extensions that are able to scan your application for annotated commands, and register them automatically.
 
-First, the `MapDiscoveredCommand<TState>`, which assumes your application only serves commands with a single service type:
+First, the `MapDiscoveredCommand<TAggregate>`, which assumes your application only serves commands for a single aggregate type:
 
 ```csharp
-app.MapDiscoveredCommands<BookingState>();
+app.MapDiscoveredCommands<Booking>();
 
 ...
 
@@ -182,18 +181,17 @@ record ProcessPayment(string BookingId, float PaidAmount);
 
 For it to work, all the commands must be annotated and have the route defined in the annotation.
 
-The second extension will discover all the annotated commands, which need to have an association with the command service type by using the `StateType` argument
-of the attribute, or by using the `HttpCommands` attribute on the container class (described above):
+The second extension will discover all the annotated commands, which need to have an association with the aggregate type by using the `Aggregate` argument of the attribute, or by using the `AggregateCommands` attribute on the container class (described above):
 
 ```csharp
 app.MapDiscoveredCommands();
 
 ...
 
-[HttpCommand<BookingState>(Route = "bookings/payment")] 
+[HttpCommand<Booking>(Route = "bookings/payment")] 
 record ProcessPayment(string BookingId, float PaidAmount);
 
-[HttpCommands<PaymentState>]
+[AggregateCommands<Payment>]
 class V1.PaymentCommands {
     [HttpCommand(Route = "payments/register")]
     public record RegisterPayment(string PaymentId, string Provider, float Amount);
@@ -209,86 +207,13 @@ Both extensions will scan the current assembly by default, but you can also prov
 app.MapDiscoveredCommands(typeof(V1.PaymentCommands).Assembly);
 ```
 
-## Command separation and enrichment
-
-Eventuous supports converting external (public) commands to internal (private) commands, as well as enriching commands with data that isn't coming directly via
-the message (as, HTTP or gRPC message) but is available in the transport context (`HttpContext` as an example).
-
-Here are some example cases for this:
-
-* Convert external HTTP commands to internal domain commands. It allows using value objects for internal commands and support early validation of the values
-  provided in the HTTP call, and avoid unnecessary reads from the database if the request is invalid.
-* Convert commands in multiple API versions to the same domain commands.
-* Populating command properties with values available in the transport context, like `HttpContext.User`.
-
-### For controllers
-
-When using the `CommandHttpApiBase` for controllers, you can provide an optional command map that instructs the controller how the HTTP API contract can be
-enriched with `HttpContext` data or converted to a different command type. You'd need to add all command transformations and enrichments to the command map, so
-it can be used across all the controllers.
-
-When you want to separate internal and external commands, commands could be defined like this:
-
-```csharp 
-// HTTP contract
-public record RegisterPaymentHttp(
-    string         BookingId,
-    string         PaymentId,
-    float          Amount,
-    DateTimeOffset PaidAt
-);
-
-// Domain command using value objects
-public record RecordPayment(
-    BookingId      BookingId,
-    string         PaymentId,
-    Money          Amount,
-    DateTimeOffset PaidAt,
-    string         PaidBy // Additional information fro HttpContext
-);
-```
-
-For example, the code below creates an instance of a command map and adds one transformation to it:
-
-```csharp
-var commandMap = new CommandMap<HttpContext>()
-    .Add<RegisterPaymentHttp, RecordPayment>((x, ctx) => 
-        new(
-            new BookingId(x.BookingId), 
-            x.PaymentId, 
-            new Money(x.Amount), 
-            x.PaidAt, 
-            ctx.User.Identity?.Name
-        )
-    );
-```
-
-Of course, if you don't want to separate external and internal commands, you can use the same but simplified technique. In that case, you'd want to hide the
-additional property using the `JsonIgnore` attribute, so it doesn't show up in the OpenAPI spec.
-
-```csharp
-public record RegisterPayment(BookingId Id, string PaymentId, Money Amount, LocalDate PaidAt) {
-    [JsonIgnore] 
-    string? PaidBy {get; init; }
-}
-
-var commandMap = new CommandMap<HttpContext>()
-    .Add<RecordPayment>((x, ctx) => x with { PaidBy = ctx.User.Identity?.Name });
-```
-
-For using the command map in controllers, you'd need to register it in the DI container as a singleton:
-
-```csharp title="Program.cs"
-builder.Services.AddSingleton(commandMap);
-```
+### Using HttpContext data
 
-### For generated routes
+Commands processed by the command service might include properties that aren't provided by the API client, but are available in the `HttpContext` object. For example, you can think about the user that is making the request. The details about the user, and the user claims, are available in `HttpContext`.
 
-It's possible to assign command properties from `HttpContext` when using extended versions of the `MapCommand` function. This method doesn't work with
-discovered commands.
+You can instruct Eventuous to enrich the command before it gets sent to the command service, using the `HttpContext` data. In that case, you also might want to hide the command property from being exposed to the client in the OpenAPI spec.
 
-First, you'd want to hide properties that are populated from `HttpContext` so they don't show up in the OpenAPI spec. To hide a property from being exposed to
-the client, use the `JsonIgnore` attribute:
+To hide a property from being exposed to the client, use the `JsonIgnore` attribute:
 
 ```csharp
 [HttpCommand(Route = "book")]
@@ -297,58 +222,10 @@ public record BookRoom(string RoomId, string BookingId, [property: JsonIgnore] s
 
 Then, you can use the `HttpContext` data in your command:
 
-```csharp title="Program.cs"
-var app = builder.Build();
-
+```csharp
 app
-    .MapCommands<BookingState>()
+    .MapAggregateCommands<Booking>()
     .MapCommand<BookRoom>((cmd, ctx) => cmd with { UserId = ctx.User.Identity.Name });
 ```
 
-When the command is mapped to the API endpoint like that, and the property is ignored, the OpenAPI specification won't include the ignored property, and the
-command service will get the command populated with the user id from `HttpContext`.
-
-Uou can also use the `Map` method to map the contract to the domain command. You can also use data from the `HttpContext` to add additional information to the
-command, like the user identity. There's no need to add ignored properties to the contract in this case.
-
-Consider the contract record being decorated by the `HttpCommand` attribute:
-
-```csharp title="HTTP contract"
-[HttpCommand(Route = "pay")]
-public record RegisterPaymentHttp(
-    string         BookingId,
-    string         PaymentId,
-    float          Amount,
-    DateTimeOffset PaidAt
-);
-```
-
-We can then define the domain command with an additional `PaidBy` property:
-
-```csharp title="Domain command"
-public record RecordPayment(
-    BookingId      BookingId,
-    string         PaymentId,
-    Money          Amount,
-    DateTimeOffset PaidAt,
-    string         PaidBy // Additional information fro HttpContext
-);
-```
-
-Then, use a more advanced overload of `MapCommand` to apply transformation and enrichment:
-
-```csharp title="Program.cs"
-var app = builder.Build();
-
-app
-    .MapCommands<BookingState>()
-    .MapCommand<ProcessPaymentHttp, Commands.ProcessPayment>(
-        (cmd, ctx) => new Commands.ProcessPayment(
-            new BookingId(cmd.BookingId), // Create value object from primitive
-            cmd.PaymentId,                // Use primitive
-            new Money(cmd.Amount),
-            cmd.PaidAt,
-            ctx.User.Identity.Name        // Use HttpContext to get user details
-        )
-    );
-```
+When the command is mapped to the API endpoint like that, and the property is ignored, the OpenAPI specification won't include the ignored property, and the command service will get the command populated with the user id from `HttpContext`.
diff --git a/docs/src/content/docs/application/command-map.mdx b/docs/src/content/docs/application/command-map.mdx
new file mode 100644
index 000000000..6659d30f0
--- /dev/null
+++ b/docs/src/content/docs/application/command-map.mdx
@@ -0,0 +1,216 @@
+---
+title: "Command mapping"
+description: "Mapping contracts to domain commands"
+sidebar:
+  order: 40
+---
+import Highlight from '@components/Highlight.astro';
+
+## Motivation
+
+In Eventuous samples you find commands that are defined using primitive value types like `string` or `int`. Such commands can be used as external contracts for application APIs. Sometimes, contract classes are referred to as DTOs (Data Transfer Objects). Probably the most important attribute of DTOs is that they are easily serializable and deserializable. Using DTOs enable interoperability between different applications and languages. You can, for example, call an API built with .NET from a frontend application written in JavaScript.
+
+You might, however, wish to keep contract definitions on the edge, and make commands a part of your domain model. II can be useful when your domain model is being exposed to different edge interfaces, such as HTTP APIs, gRPC services, or message brokers. In such cases, you might want to use different contract classes for different interfaces. For example, you might want to use a different contract for a gRPC service than for a HTTP API, especially because gRPC contracts are generated from proto files.
+
+Another reason to embed commands to the domain model is the ability to use value objects in commands, which is not recommended for external contracts. Value objects are a great way to model complex data structures, and they are a part of the domain model. However, value objects usually enforce instantiation rules that can break serialization.
+
+Eventuous allows you to separate contract definitions from domain commands. You can define contracts as POCOs (Plain Old C# Objects) and map them to domain commands. This way you can use different contracts for different interfaces, and you can use value objects in commands. Apart from the benefit of conceptual separation, it also allows to fail invalid requests to the API early, before the command is passed to the command service.
+
+### Using DTOs as commands
+
+Here's how command handling usually works:
+
+- API endpoint:
+  - Receives a request
+  - The request is deserialized to a command contract
+  - The command is passed to the command service
+- Command service
+  - Loads an aggregate or a stream <Highlight color="blue">**database call**</Highlight>
+  - Creates the necessary value objects <Highlight color="red">**can fail**</Highlight>
+  - Calls the domain model operation
+  - Persists new events
+  - Returns the result
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant API Endpoint
+    participant Command Service
+    participant Domain
+    participant Event Store
+
+    Client->>+API Endpoint: Request
+    API Endpoint->>API Endpoint: Deserialize request
+    API Endpoint->>+Command Service: Command
+    Command Service->>+Event Store: Load
+    Event Store-->>-Command Service: Events
+    Command Service->>Command Service: Create value objects
+    alt
+        Note right of Command Service: Can fail!
+        Command Service-->>API Endpoint: Return error
+        API Endpoint-->>Client: Return error
+    end
+    Command Service->>+Domain: Execute
+    Domain-->>-Command Service: New events
+    Command Service->>+Event Store: New events
+    Event Store-->>-Command Service: Return result
+    Command Service-->>-API Endpoint: Return result
+    API Endpoint-->>-Client: Return result
+```
+
+As you can see, the command service would load events from event store before creating value objects. This is not a problem if the command is valid, but if the command is invalid, the value object creation will fail, and the request will be rejected. However, the command service will still load events from the event store, which is a waste of resources.
+
+### Using mapped commands
+
+When using mapped command, the flow changes:
+
+- Command service
+  - Maps the contract to a domain command <Highlight color="red">**can fail**</Highlight>
+  - Loads an aggregate or a stream <Highlight color="blue">**database call**</Highlight>
+  - Calls the domain model operation
+  - Persists new events
+  - Returns the result
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant API Endpoint
+    participant Command Service
+    participant Event Store
+    participant Domain
+
+    Client->>+API Endpoint: Request
+    API Endpoint->>API Endpoint: Deserialize request
+    API Endpoint->>API Endpoint: Convert to command
+    alt
+        Note right of API Endpoint: Can fail!
+        API Endpoint-->>Client: Return error
+    end
+    API Endpoint->>+Command Service: Command
+    Command Service->>+Event Store: Load
+    Event Store-->>-Command Service: Events
+    Command Service->>+Domain: Execute
+    Domain-->>-Command Service: New events
+    Command Service->>+Event Store: New events
+    Event Store-->>-Command Service: Return result
+    Command Service-->>-API Endpoint: Return result
+    API Endpoint-->>-Client: Return result
+```
+
+As you can see, the value object creation is executed early, and when the command is invalid, the request is rejected before executing any database operation.
+
+## Implementation
+
+Depending on the API implementation pattern, you can use different ways to map contracts to domain commands.
+
+Consider the following example:
+
+```csharp title="Command contract"
+public record RegisterPaymentHttp(
+    string         BookingId,
+    string         PaymentId,
+    float          Amount,
+    DateTimeOffset PaidAt
+);
+```
+
+```csharp title="Domain command"
+public record RecordPayment(
+    BookingId BookingId,
+    string PaymentId,
+    Money Amount,
+    DateTimeOffset PaidAt
+);
+```
+
+There, you notice that the domain command uses value objects, and the contract only uses primitive types.
+
+### Using controller base
+
+When you implement your API using the `CommandHttpApiBase` or `CommandHttpApiBaseFunc` [base classes](../command-api#controller-base), you can provide the command mapper as a dependency. The mapper needs to be instantiated before the application starts, and injected to the controller.
+
+Here is how the mapping is defined:
+
+```csharp title="Program.cs"
+var commandMap = new MessageMap()
+    .Add<BookingApi.RegisterPaymentHttp, Commands.RecordPayment>(
+        x => new Commands.RecordPayment(
+            new BookingId(x.BookingId),
+            x.PaymentId,
+            new Money(x.Amount),
+            x.PaidAt
+        )
+    );
+
+builder.Services.AddSingleton(commandMap);
+```
+
+You can chain `Add` calls to map as many commands as you need.
+
+Then, in the controller you need to use the `Handle<TContract, TCommand>` base class method, which will force the controller base to use the mapper to convert the contract to a domain command.
+
+```csharp title="BookingController.cs"
+public class BookingApi : CommandHttpApiBase<Booking> {
+    public BookingApi(
+        ICommandService<Booking> service,
+        MessageMap? commandMap = null
+    ) : base(service, commandMap) { }
+
+    [HttpPost("v2/pay")]
+    public Task<ActionResult<Result>> RegisterPayment(
+        [FromBody] RegisterPaymentHttp cmd,
+        CancellationToken cancellationToken
+    )
+        => Handle<RegisterPaymentHttp, Commands.RecordPayment>(cmd, cancellationToken);
+}
+```
+
+### Using generated endpoints
+
+When you use the [generated endpoints](../command-api#generated-command-api), you can use the `Map` method to map the contract to the domain command. You can also use data from the `HttpContext` to add additional information to the command, like the user identity. There's no need to add ignored properties to the contract in this case.
+
+Consider the contract record being decorated by the `HttpCommand` attribute:
+
+```csharp title="Command contract"
+[HttpCommand(Route = "pay")]
+public record RegisterPaymentHttp(
+    string         BookingId,
+    string         PaymentId,
+    float          Amount,
+    DateTimeOffset PaidAt
+);
+```
+
+We can then define the domain command with an additional `PaidBy` property:
+
+```csharp title="Domain command"
+public record RecordPayment(
+    BookingId      BookingId,
+    string         PaymentId,
+    Money          Amount,
+    DateTimeOffset PaidAt,
+    string         PaidBy // Additional information fro HttpContext
+);
+```
+
+Here's how the mapping is defined:
+
+```csharp title="Program.cs"
+var app = builder.Build();
+
+app
+    .MapAggregateCommands<Booking>
+    .MapCommand<ProcessPaymentHttp, Commands.ProcessPayment>(
+        (cmd, ctx) => new Commands.ProcessPayment(
+            new BookingId(cmd.BookingId), // Create value object from primitive
+            cmd.PaymentId,                // Use primitive
+            new Money(cmd.Amount),
+            cmd.PaidAt,
+            ctx.User.Identity.Name        // Use HttpContext to get user details
+        )
+    );
+```
+
+:::caution
+Generated endpoints currently don't support [functional command services](../func-service). This functionality will be added in a future version.
+:::
diff --git a/docs/src/content/docs/application/func-service.md b/docs/src/content/docs/application/func-service.md
new file mode 100644
index 000000000..7426e869a
--- /dev/null
+++ b/docs/src/content/docs/application/func-service.md
@@ -0,0 +1,142 @@
+---
+title: "Functional service"
+description: "Functional command service and unit of work without aggregates"
+sidebar:
+  order: 20
+---
+
+## Concept
+
+The functional command service is an alternative way to handle commands. There, you don't use aggregates for the domain model. Instead, you define a set of stateless functions that receive the restored state instance and the collection of previously stored events, and produces new events. The service performs the following operations when handling one command:
+1. Extract the stream name from the command, if necessary.
+2. Instantiate all the necessary value objects. This could effectively reject the command if value objects cannot be constructed. The command service could also load some other streams, or any other information, which is needed to execute the command but won't change state.
+3. If the command expects to operate on an existing stream, the stream events get loaded from the [Event Store](../../persistence/event-store).
+4. Restore state from the loaded events.
+5. Execute an operation on the loaded (or new) state and events, using values from the command, and the constructed value objects.
+6. The function either performs the operation and produces new events, or rejects the operation. It can also do nothing.
+7. If the operation was successful, the service persists new events to the store. Otherwise, it returns a failure to the edge.
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant API Endpoint
+    participant Command Service
+    participant Domain Module
+    participant Event Store
+
+    Client->>+API Endpoint: Request
+    API Endpoint->>API Endpoint: Deserialize request
+    API Endpoint->>+Command Service: Command
+    Command Service->>+Event Store: Load stream
+    Event Store-->>-Command Service: Events
+    Command Service->>+Domain Module: Execute
+    Domain Module-->>-Command Service: New events
+    Command Service->>+Event Store: Append events
+    Event Store-->>-Command Service: Return result
+    Command Service-->>-API Endpoint: Return result
+    API Endpoint-->>-Client: Return result
+```
+
+:::caution[Handling failures]
+The last point above translates to: the command service **does not throw exceptions**. It [returns](../app-service#result) an instance of `ErrorResult` instead. It is your responsibility to handle the error.
+:::
+
+## Implementation
+
+Eventuous provides a base class for you to build functional command services. It is a generic abstract class, which is typed to the state type. You should create your own implementation of a service for each state type. As command execution is transactional, it can only operate on a single stream, and, logically, only one state type. However, there is no strong link between the state type and the stream name. You can use the same state type for multiple streams, or use different state types for the same stream.
+
+### Handling commands
+
+The base class has three methods, which you call in your class constructor to register the command handlers:
+
+| Function     | What's it for                                                                                                                                                                                                                                                          |
+|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `OnNew`      | Registers the handler, which expects that the stream doesn't exist. It will get a new state object instance. The operation will fail when it will try storing events due to version mismatch.                                                                          |
+| `OnExisting` | Registers the handler, which expect an existing stream where it will load events from. You need to provide a function to extract the stream name from the command. The handler will get the events loaded from the store, and will throw if there's no stream to load. |
+| `OnAny`      | Used for handlers, which can operate both on new and existing streams. The command service will _try_ to load events from the given stream, but won't throw if the load fails, and will pass a new state instance instead.                                             |
+
+Here is an example of a functional command service form our test project:
+
+```csharp title="BookingFuncService.cs"
+public class BookingFuncService : FunctionalCommandService<BookingState> {
+    public BookingFuncService(IEventStore store, TypeMapper? typeMap = null) : base(store, typeMap) {
+        // Register command handlers
+        OnNew<BookRoom>(cmd => GetStream(cmd.BookingId), BookRoom);
+        OnExisting<RecordPayment>(cmd => GetStream(cmd.BookingId), RecordPayment);
+
+        // Helper function to get the stream name from the command
+        static StreamName GetStream(string id) => new StreamName($"Booking-{id}");
+
+        // When there's no stream to load, the function only receives the command
+        static IEnumerable<object> BookRoom(BookRoom cmd) {
+            yield return new RoomBooked(cmd.RoomId, cmd.CheckIn, cmd.CheckOut, cmd.Price);
+        }
+
+        // For an existing stream, the function receives the state and the events
+        static IEnumerable<object> RecordPayment(
+            BookingState state, 
+            object[] originalEvents, 
+            RecordPayment cmd
+        ) {
+            if (state.HasPayment(cmd.PaymentId)) yield break;
+
+            var registered = new BookingPaymentRegistered(cmd.PaymentId, cmd.Amount.Amount);
+
+            yield return registered;
+
+            // Apply the payment to the state
+            var newState = state.When(registered);
+            if (newState.IsFullyPaid()) 
+                yield return new BookingFullyPaid(cmd.PaidAt);
+            if (newState.IsOverpaid()) 
+                yield return new BookingOverpaid((state.AmountPaid - state.Price).Amount);
+        }
+    }
+}
+```
+
+The service uses the same `BookingState` record as described on the [State](../../domain/state) page.
+
+### Usage
+
+Because the functional service base class implements the same `ICommandService` interface, it can be used the same way as any other command service, by calling the `Handle<TCommand>` method from the API controller. You can, therefore, use it in API controllers similar to the command service:
+
+```csharp title="Api/Bookings.cs"
+[Route("/booking")]
+public class CommandApi : ControllerBase {
+    IFuncCommandService<Booking> _service;
+
+    public CommandApi(IFuncCommandService<Booking> service) 
+        => _service = service;
+
+    [HttpPost]
+    [Route("book")]
+    public async Task<ActionResult<Result>> BookRoom(
+        [FromBody] BookRoom cmd, 
+        CancellationToken cancellationToken
+    ) {
+        var result = await _service.Handle(cmd, cancellationToken);
+        result Ok(result);
+    }
+}
+```
+
+:::caution
+Mapping commands to HTTP endpoints won't work with functional services. These features are coming in upcoming releases.
+:::
+
+You can also use the `CommandHttpApiBaseFunc` base class as described on the [command API](../command-api) page.
+
+### Registration
+
+You can add a functional service to the DI container using the `AddFunctionalService` extensions methods:
+
+```csharp title="Program.cs"
+// Any dependency will be injected
+builder.Services.AddFunctionalService<BookingFuncService, BookingState>();
+
+// Specify dependencies explicitly
+builder.Services.AddFunctionalService(sp => 
+    new AnotherFuncService(sp.GetRequiredService<IEventStore>(), customTypeMap)
+);
+```
diff --git a/docs/src/content/docs/application/index.mdx b/docs/src/content/docs/application/index.mdx
index f5eab53b8..7144a9aae 100644
--- a/docs/src/content/docs/application/index.mdx
+++ b/docs/src/content/docs/application/index.mdx
@@ -1,8 +1,7 @@
 ---
 title: "Application"
 description: "Application layer and service"
-sidebar:
-  order: 2
+order: 1
 ---
 
 The application layer sits between the system edge (different APIs), and the domain model. It is responsible for handling commands coming from the edge.
diff --git a/docs/src/content/docs/diagnostics/details.md b/docs/src/content/docs/diagnostics/details.md
new file mode 100644
index 000000000..700a7bf3c
--- /dev/null
+++ b/docs/src/content/docs/diagnostics/details.md
@@ -0,0 +1,193 @@
+---
+title: "Diagnostics"
+---
+
+# Diagnostics in details
+
+Eventuous provides built-in metrics and traces for:
+- Event store
+- Subscriptions, consumers, and event handlers
+- Command services
+- Producers
+
+The built-in diagnostics integrate with [OpenTelemetry](https://opentelemetry.io/) using [OpenTelemetry .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/observability-with-otel).
+
+## Enabling diagnostics
+
+Diagnostic instrumentation is enabled by default. You can disable it by setting the `EVENTUOUS_DISABLE_DIAGS` environment variable to any value except `1`. It is also possible to disable diagnostics at runtime by calling `EventuousDiagnostics.Disable()` static function.
+
+When diagnostics are enabled, registering different Eventuous elements will wrap them in diagnostic decorators. The decorators collect metrics and traces for the registered elements. For example, when registering an event reader using `AddEventReader` extension, the provided event reader type will be used by `TracedEventReader` decorator, which collects metrics and traces for the event reader.
+
+## Logging
+
+Eventuous uses the ASP.NET Core logging with `ILoggerFactory` and `ILogger<T>`, so you can use the standard logging facilities to log diagnostics. For internal logging, Eventuous uses multiple [event sources](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/eventsource), which you can collect and analyse with tools like `dotnet-trace`.
+
+It's also possible to expose internal Eventuous logs using the `UseEventuousLogs` extension for `IHost`, which is available as part of `Eventuous.Extensions.DependencyInjection` package.
+
+## Metrics
+
+Metrics are collected using several `Meter` instances. There are two available meters:
+
+- `eventuous.application` for command services
+- `eventuous.subscriptions` for subscriptions
+- `eventuous.persistence` for event stores
+
+Producers do not provide meters, but you can use traces to collect diagnostics for producers.
+
+### Application metrics
+
+Application metrics are collected for command services. The metrics are collected for the duration and error count of command processing. The metrics are tagged by:
+
+- `command-service`: the service type
+- `command-type`: command type
+
+Command handling duration is collected as a histogram with the name `eventuous_service_duration` with measure unit `milliseconds`. The number of errors that occurred when handling commands is collected as a counter with the name `eventuous_service_errors_count`.
+
+Here's an example of command service metrics exported in Prometheus format:
+
+```txt
+# TYPE eventuous_service_duration_milliseconds histogram
+# UNIT eventuous_service_duration_milliseconds milliseconds
+# HELP eventuous_service_duration_milliseconds Command execution duration, milliseconds
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="0"} 0 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="5"} 0 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="10"} 0 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="25"} 0 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="50"} 0 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="75"} 0 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="100"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="250"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="500"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="750"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="1000"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="2500"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="5000"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="7500"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="10000"} 1 1725881998415
+eventuous_service_duration_milliseconds_bucket{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom",le="+Inf"} 1 1725881998415
+eventuous_service_duration_milliseconds_sum{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom"} 86.583 1725881998415
+eventuous_service_duration_milliseconds_count{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom"} 1 1725881998415
+# TYPE eventuous_service_errors_count_total counter
+# UNIT eventuous_service_errors_count_total errors
+# HELP eventuous_service_errors_count_total Number of failed commands
+eventuous_service_errors_count_total{otel_scope_name="eventuous.application",otel_scope_version="0.15.0.0",command_service="BookingsCommandService",command_type="BookRoom"} 1 1725881998415
+```
+
+### Persistence metrics
+
+When Eventuous diagnostics is enabled (by default), registering any persistence component like event reader, writer or store will wrap it in a diagnostic decorator. The decorator collects persistence metrics. The metrics are tagged by:
+
+- `operation`: the operation type (`append`, `read`, etc)
+- `component`: the persistence implementation type (derived from the concrete class name at runtime), for example `KurrentDBEventStore`
+
+Persistence operation duration is collected as a histogram with the name `eventuous_persistence_duration` with measure unit `milliseconds`. The number of errors that occurred when executing persistence operations is collected as a counter with the name `eventuous_persistence_errors_count`.
+
+Here's an example of persistence metrics exported in Prometheus format:
+
+```txt
+# TYPE eventuous_persistence_duration_milliseconds histogram
+# UNIT eventuous_persistence_duration_milliseconds milliseconds
+# HELP eventuous_persistence_duration_milliseconds Event store operation duration, milliseconds
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="0"} 0 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="5"} 0 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="10"} 0 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="25"} 0 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="50"} 0 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="75"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="100"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="250"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="500"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="750"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="1000"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="2500"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="5000"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="7500"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="10000"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_bucket{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append",le="+Inf"} 1 1725888603727
+eventuous_persistence_duration_milliseconds_sum{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append"} 66.672 1725888603727
+eventuous_persistence_duration_milliseconds_count{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append"} 1 1725888603727
+# TYPE eventuous_persistence_errors_count_total counter
+# UNIT eventuous_persistence_errors_count_total errors
+# HELP eventuous_persistence_errors_count_total Number of failed event store operations
+eventuous_persistence_errors_count_total{otel_scope_name="eventuous.persistence",otel_scope_version="0.15.0.0",component="KurrentDBEventStore",operation="append"} 1 1725888603727
+```
+
+### Subscription metrics
+
+Subscription metrics are described in the [subscriptions diagnostics](../../subscriptions/subs-diagnostics#subscription-metrics) page.
+
+## Tracing
+
+Eventuous uses .NET `Activity` API to trace operations for command services, persistence, subscriptions, and producers. When OpenTelemetry integration is enabled, the traces are exported to the configured exporter.
+
+### Command service tracing
+
+Command handling operation creates a span with the name that is a combination of the command service name and the command type. For example, a service called `BookingsCommandService` processing a command `BookRoom` would create a span `service.bookingscommandservice/bookroom`. The span is tagged with the command name attribute as well. The tag name is `eventuous.command`.
+
+If the command handler fails, the span will be set as failed and the exception will be attached to the span.
+
+### Persistence tracing
+
+Persistence operations create a span with the name that is a combination of the operation name and the stream name. For example, appending events to the stream `Booking-128` would create a span `eventstore.append/booking-128`. The span is tagged with the operation name and the stream name attributes. The tag names are `db.operation` and `eventuous.stream`. In addition, the `db.system` tag is set to `eventstore`.
+
+If the operation fails, the span will be set as failed and the exception will be attached to the span.
+
+### Producer tracing
+
+Producers operations create a span with the name `produce`. The span is tagged with the following attributes:
+
+* `eventuous.stream`: name of the stream, topic or exchange where the message is produced to
+* `message_type`: type of the message, only when one message is produced
+* `message_id`: ID of the message, only when one message is produced
+* `messaging_destination`: same value as `eventuous.stream`
+* `messaging.message_id`: same value as `message_id`
+* `messaging.destination_kind`: type of the destination, for example `stream`, `exchange`, etc.
+* `messaging.system`: name of the messaging system, for example `rabbitmq`, `eventstoredb`, etc.
+* `messaging.operation`: operation name, for example `produce`, `append`, etc.
+
+### Subscription tracing
+
+Subscription tracing is described in the [subscriptions diagnostics](../../subscriptions/subs-diagnostics#subscription-tracing) page.
+
+## OpenTelemetry integration
+
+Eventuous uses OpenTelemetry .NET to collect and export metrics and traces. The integration requires `Eventuous.Diagnostics.OpenTelemetry` package to be installed. The package provides extensions for OpenTelemetry .NET hosting and configuration.
+
+### Adding metrics
+
+Use two extensions for `MetricsProviderBuilder` to add Eventuous metrics:
+
+```csharp
+builder.Services.AddOpenTelemetry()
+    .WithMetrics(
+        builder => {
+            builder
+                .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("MyService"))
+                .AddEventuous()
+                .AddEventuousSubscriptions()
+                .AddPrometheusExporter();
+        }
+    );
+```
+
+* `AddEventuous` adds application and persistence metrics
+* `AddEventuousSubscriptions` adds subscription metrics
+
+### Adding traces
+
+Use `AddEventuousTracing` extension to `TracerProviderBuilder` to add Eventuous traces:
+
+```csharp
+builder.Services.AddOpenTelemetry()
+    .WithTracing(
+        builder => {
+            builder
+                .AddEventuousTracing()
+                .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("MyService"))
+                .SetSampler(new AlwaysOnSampler())
+                .AddZipkinExporter();
+        }
+    );
+```
+
+Because all Eventuous traces use the same activity source, using `AddEventuousTracing` that connects OpenTelemetry .NET with the activity source will automatically collect traces for all Eventuous components.
\ No newline at end of file
diff --git a/docs/src/content/docs/domain/aggregate.md b/docs/src/content/docs/domain/aggregate.md
index cc7c83ca1..d8721c112 100644
--- a/docs/src/content/docs/domain/aggregate.md
+++ b/docs/src/content/docs/domain/aggregate.md
@@ -6,11 +6,7 @@ sidebar:
 ---
 
 :::info
-From version **0.14.0** using aggregates is **optional**. You can define your domain logic using [functional services](../../application/func-service) instead.
-:::
-
-:::info
-From version **0.15.0**, non-generic `Aggregate` abstraction is gone, so you have to use `Aggregate<TState>`.
+From version 0.14.0 using aggregates is **optional**. You can define your domain logic using [functional services](../../application/func-service) instead.
 :::
 
 ## Concept
@@ -167,9 +163,7 @@ public delegate T AggregateFactory<out T, TState>() where T : Aggregate<TState>;
 The registry allows you to add custom factory for a particular aggregate type. The registry itself is a singleton, accessible by `AggregateFactoryRegistry.Instance`. You can register your custom factory by using the `CreateAggregateUsing<T>` method of the registry:
 
 ```csharp title="Program.cs"
-AggregateFactoryRegistry.CreateAggregateUsing<Booking, BookingState>(
-    () => new Booking(availabilityService)
-);
+AggregateFactoryRegistry.CreateAggregateUsing<Booking, BookingState>(() => new Booking(availabilityService));
 ```
 
 By default, when there's no custom factory registered in the registry for a particular aggregate type, Eventuous will create new aggregate instances by using reflections. It will only work when the aggregate class has a parameterless constructor (it's provided by the `Aggregate` base class).
@@ -178,10 +172,6 @@ It's not a requirement to use the default factory registry singleton. Both `Comm
 
 ### Dependency injection
 
-:::note
-Install the `Eventuous.Extensions.DependencyInjection` package to use the API described below.
-:::
-
 The aggregate factory can inject registered dependencies to newly created aggregate instances when constructing them. For this to work, you need to tell Eventuous that the aggregate needs to be constructed using the container. To do so, use the `AddAggregate<T, TState>` service collection extension:
 
 ```csharp title="Program.cs"
@@ -197,3 +187,4 @@ When that's done, you also need to tell the host to use the registered factories
 app.UseAggregateFactory();
 ```
 
+These extensions are available in the `Eventuous.Extensions.DependencyInjection` package.
diff --git a/docs/src/content/docs/domain/domain-events.md b/docs/src/content/docs/domain/domain-events.md
index f5e2d1fc7..face358d5 100644
--- a/docs/src/content/docs/domain/domain-events.md
+++ b/docs/src/content/docs/domain/domain-events.md
@@ -51,14 +51,14 @@ public static class BookingEvents {
 }
 ```
 
+Oh, that's it? A record? Yes, a record. Domain events are property bags. Their only purpose is to convey the state transition using the language of your domain. Technically, a domain event should just be an object, which can be serialised and deserialized for the purpose of persistence.
+
 Eventuous do's and dont's:
-- **Do** make sure your domain events can be serialized to a commonly understood format, like JSON.
+- **Do** make sure your domain events can be serialised to a commonly understood format, like JSON.
 - **Do** make domain events immutable.
 - **Do** implement equality by value for domain events.
 - **Don't** apply things like marker interfaces (or any interfaces) to domain events.
 - **Don't** use constructor logic, which can prevent domain events from deserializing.
 - **Don't** use value objects in your domain events.
 
-Some of those points look like limitations, and they are. For example, avoiding value objects inside domain events primarily caused by lack of separation between domain events and persisted (stored in an [event store](../../persistence/event-store)) events. It creates a requirement for the domain events to be fully (de)serializable, and it's not always possible when using value objects with their explicit validation rules. You also cannot use standard types like immutable arrays or lists as they cannot be deserialized.
-
-It's a technical limitation which will be addressed soon.
+The last point might require some elaboration. The `Value Object` pattern in DDD doesn't only require for those objects to be immutable and implement equality by value. The main attribute of a value object is that it must be _correct_. It means that you can try instantiating a value object with invalid arguments, but it will deny them. This characteristic along forbids value objects from being used in domain events, as events must be _unconditionally deserializable_. No matter what logic your current domain model has, events from the past are equally valid today. By bringing value objects to domain events you make them prone to failure when their validity rules change, which might prevent them from being deserialized. As a result, your aggregates won't be able to restore their state from previously persistent events and nothing will work.
diff --git a/docs/src/content/docs/domain/state.md b/docs/src/content/docs/domain/state.md
index 577292d37..9fee0cf4d 100644
--- a/docs/src/content/docs/domain/state.md
+++ b/docs/src/content/docs/domain/state.md
@@ -15,10 +15,6 @@ A record, which inherits from `State` needs to implement a single function calle
 
 ### Using pattern matching
 
-:::tip[Use explicit handlers]
-Eventuous performs additional checks if event types, which are handled by the `When` function, are registered in the type map. If you use pattern matching, the check is impossible to perform, and the application can crash if the event is not registered in the type map. Therefore, we advise to use explicit handlers as described [below](#using-explicit-handlers).
-:::
-
 Using pattern matching, you can define how events mutate the state with functions that return the new `State` instance.
 
 For example:
@@ -42,9 +38,13 @@ Although it is possible to use pattern matching, we recommend using explicit han
 
 ### Using explicit handlers
 
+:::tip[Use explicit handlers]
+Eventuous performs additional checks if event types, which are handled by the `When` function, are registered in the type map. If you use pattern matching, the check is impossible to perform, and the application can crash if the event is not registered in the type map.
+:::
+
 You can also use explicit event handlers, where you define one function per event, and register them in the constructor. In that case, there's no need to override the `When` function.
 
-The syntax is simple, allowing you to add separate functions for applying each event type to the state:
+The syntax is similar to registered command handlers for the [command service](../../application):
 
 ```csharp title="BookingState.cs"
 public record BookingState : State<BookingState> {
@@ -66,23 +66,26 @@ public record BookingState : State<BookingState> {
         On<BookingPaymentRegistered>(
             (state, paid) => state with {
                 AmountPaid = state.AmountPaid + new Money(paid.AmountPaid),
-                _payments = state._payments.Add(
+                _registeredPayments = state._registeredPayments.Add(
                     new Payment(paid.PaymentId, new Money(paid.AmountPaid))
                 )
             }
         );
     }
 
-    ImmutableArray<Payment> _payments = ImmutableArray<Payment>.Empty;
+    ImmutableArray<Payment> _registeredPayments = ImmutableArray<Payment>.Empty;
 
     public Money Price      { get; private init; }
     public Money AmountPaid { get; private init; }
 
-    public bool IsFullyPaid() => AmountPaid.Amount >= Price.Amount;
+    public bool IsFullyPaid()
+        => AmountPaid.Amount >= Price.Amount;
 
-    public bool IsOverpaid() => AmountPaid.Amount > Price.Amount;
+    public bool IsOverpaid()
+        => AmountPaid.Amount > Price.Amount;
 
-    public bool HasPayment(string paymentId) => _payments.Any(p => p.PaymentId == paymentId);
+    public bool HasPayment(string paymentId)
+        => _registeredPayments.Any(p => p.PaymentId == paymentId);
 
     record Payment(string PaymentId, Money Amount);
 }
@@ -110,4 +113,4 @@ public record BookingState<BookingId> {
 }
 ```
 
-The `BookingState` type will have a property named `Id` of type `BookingId`. You don't need to set it manually as it will be provided when the state object is recreated from events by the command service.
\ No newline at end of file
+The `BookingState` type will have a property named `Id` of type `BookingId`. You don't need to set it manually as it will be provided when the state object is recreated from events by the [command service](../../application/app-service).
\ No newline at end of file
diff --git a/docs/src/content/docs/faq/compare.md b/docs/src/content/docs/faq/compare.md
index c6fb6be06..785864ed0 100644
--- a/docs/src/content/docs/faq/compare.md
+++ b/docs/src/content/docs/faq/compare.md
@@ -3,44 +3,46 @@ title: "Compare"
 description: "How Eventuous is different from others?"
 ---
 
-## How is Eventuous different from other libs?
+## EventFlow
 
-You might have seen other libraries, old and new, that provide similar functionality to Eventuous. Here's how Eventuous is different:
+EventFlow is probably the most popular Event Sourcing and CQRS framework for .NET. It has a rich history, it's battle-tested and ready for production use. So, why not EventFlow?
 
-### Persistence
+### Abstractions
 
-Following EventStoreDB principles, Eventuous is build with strict global ordering in mind. It has pros and cons, and we believe that the pros outweigh the cons.
+EventFlow is full of abstractions. There's an interface for everything, including commands and events. In fact, Eventuous discourages you to use interfaces for these primitives, as they are just serializable property bags. For example, a `Command` base class in EventFlow has 60 lines of code with three constrained generic parameters, one inheritance (`ValueObject`), and it implements a generic interface `ICommand`. In Eventuous, we recommend using records, but you can use classes too.
 
-In real life events happen in certain order. Naturally, some things happen at the same time, and it is literally impossible to say if two events happened at the same time or one before another. And, we also would not care, **unless** there's a causation. There are many debates on this topic out there, where the primary argument against caring for global order is that we should only care about order of events in the same stream. This is a valid point, but it's not the only one. Events across streams might have causality, and we should care about it.
+### Codebase size
 
-The problem is that causal relationship is not easy to implement, and it's often a domain concern that cannot be abstracted to a library. However, Eventuous provides a way to implement causal _ordering_ between events in different streams by enforcing global ordering.
+We strongly believe in code, which fits in one's head. You can read all the Eventuous core library code in half an hour and understand what it does. There is no magic there. EventFlow, on the other side, has lots of interfaces and attributes that aim to prevent developers from doing the wrong thing. All those guide rails need code, which Eventuous doesn't have and will never have.
 
-As a consequence, causal ordering is available across streams without additional complexity from the domain model side.
+### Just enough
 
-However, this approach sets certain expectations for the underlying infrastructure. For example, EventStoreDB is a perfect match for Eventuous, as it provides the same guarantees. Other stores implemented by Eventuous provide the same guarantees but global ordering requirements might affect the performance.
+Unlike EventFlow, we don't provide anything special for logging, DI containers, scheduled jobs, sagas, etc. We know some open-source great tools to deal with these concerns, which are out of scope for this project. However, Eventuous plays well any DI, as well as it uses Microsoft logging abstractions.
 
-### Just enough abstractions
+## NEventStore
 
-Eventuous provides just enough abstractions to make it easy to use, but not too much to make it hard to understand. We believe that the best way to learn is to see how things work under the hood. That's why Eventuous is built with a clear separation of concerns, but without unnecessary abstractions.
+NEventStore is one of the first, if not the first library for Event Sourcing in .NET space. It is as old as the idea of Event Sourcing itself as we know it today. Quite a few people who are or were actively involved in defining what Event Sourcing is, have contributed to NEventStore. The latest version of NEventStore known at the date of writing this text is end of December 2021, and it's the version 9.0.1.
 
-Many libs and frameworks enforce abstractions on things that should not be abstracted. Mainly, it's about so-called marker interfaces) like `IEvent` or `ICommand`. Eventuous does not enforce such interfaces, as they are not necessary for the library to work.
+The library (it's not a framework) only focused on persistence. It is basically a layer on top of a regular operational database. The aim of NEventStore is to be as agnostic as possible to the underlying database. To achieve the desired level of abstraction, creators of NEventStore made some decisions that form a foundation of its design:
 
-Additionally, interfaces like `IEventHandler` are often used for things like projections, or implicit invocation of `Apply<T>` methods on aggregates. Eventuous does not use such interfaces in favour of explicit mappings of types to functions, which avoids the library to do magic behind the scenes and doesn't require to use reflections, which would be bad for performance.
+- The atomic write is a commit, which might be one or more events. All data in the commit is stored as a single object. There's no way to ensure you read of process individual events as NEventStore will always read commits.
+- There's no concept of a global event log. In fact, it's quite common for persistent libraries on top of relational databases to avoid having the global event log, arguing that it's an anti-pattern.
+- NEventStore assumes that systems are normally built as monoliths. This statement might sound strange as you can't find it in the architecture page of the documentation. However, there is an important concept of a dispatcher, which implements a flavour of the outbox pattern, and it aims to deliver events to subscribers in-process. For catch-up subscriptions, you can only find so-called "reference implementation" of the polling client, and it is located in a separate project.
+- NEventStore persistence abstraction puts substantial effort to enable using almost any SQL or NoSQL store. The documentation makes it clear that it was the goal of the creators of NEventStore. However, most of the persistence implementations are for SQL databases. Only two NoSQL databases have support that's marked as "completed" - MongoDB and RavenDB.
 
-Eventuous uses reflections carefully and only during bootstrapping.
+Without the knowledge of the initial ideas of the creators of NEventStore it seems that the fundamental decisions were made to aim to support as many databases as possible. However, even if the goal of making it possible didn't seem to pay off as implementing similar functionality on top of a SQL database would be easier, and the only popular NoSQL database that is supported by the library is MongoDB.
 
-### Latest .NET
+This challenge is easy to spot when reading the architecture page of NEventStore docs:
 
-Eventuous is relatively new, and we aim keeping it up to date with the latest features of C# and .NET. The library uses ASP.NET Core native elements like configuration, hosting, and dependency injection. It allows developers to jump-start their projects without learning new concepts, at least about the bootstrapping basics.
+> One other area where NEventStore has a distinct advantage is that of eventual consistency in the store itself. Because the storage engine is not dictated, an engine such as CouchDB, Cassandra, or Riak could be utilized which support multi-master replication.
 
-### No strong DDD focus
+Indeed, it can be a distinct advantage. Sadly, you cannot find any implementation of the persistence for any of those databases.
 
-Although Domain-Driven Design (DDD) is very useful and provides patterns that are directly applicable for event-sourced systems, there are different styles of building applications. Code patterns like Aggregate and Repository are quite old, and there's no necessity in using them everywhere. Eventuous provides a way to build event-sourced systems without enforcing DDD patterns. It's up to the developer to decide what building blocks to use.
+In contrast, Eventuous started with supporting KurrentDB only, and the persistence design was built according to the KurrentDB capabilities based on the assumption that it's a purpose-built database for Event Sourcing. It allows to keep the persistence API limited to a set of abstractions and serialization implementation, enriched with implementation of best practices like event type mappings, optimistic concurrency based on event stream revisions, and so on. When Eventuous received contributions to add Microsoft SQL Server and Postgres support, those implementations were able to implement the same API, and the persistence API didn't need to be changed. Core concept of asynchronous subscriptions are also supported for MS SQL and Postgres using continuous polling, which is a part of the implementation library that implements the subscriptions API of Eventuous.
 
-### First-class observability
+Additional challenges of using NEventStore:
 
-Eventuous implements all elements of observability like [logging](../../diagnostics/logs), [metrics](../../diagnostics/metrics), and [distributed tracing](../../diagnostics/traces).
+- The library maintains its own DI container and logging library. The user of NEventStore must implement their own wiring between those components and ASP.NET Core.
+- All the IO operations are synchronous. There's no async support. Considering that most of the modern database drivers are async-first, and synchronous calls are just blocking wrappers around async calls, it's a significant drawback.
 
-It is important to understand that observability is not only about logging and metrics. It's about understanding the system's behaviour and performance. Eventuous provides a way to trace messages across the system, which is crucial for understanding the system's behaviour. Following the current observability trends, Eventuous [integrates](../../diagnostics/opentelemetry) natively with OpenTelemetry, so applications can be configured to export traces and metrics to any APM provider that support OTLP.
-
-Particularly, each event-sourced system essentially is a distributed system, and it's important to understand how messages flow through the system. Eventuous provides a way to trace messages across the system, which is crucial for understanding the system's behaviour.
\ No newline at end of file
+Eventuous was built with the modern .NET stack in mind. It's fully asynchronous and supports ASP.NET Core dependency injection container and logging abstractions.
\ No newline at end of file
diff --git a/docs/src/content/docs/faq/compatibility.md b/docs/src/content/docs/faq/compatibility.md
index 75e78c372..9982bcab6 100644
--- a/docs/src/content/docs/faq/compatibility.md
+++ b/docs/src/content/docs/faq/compatibility.md
@@ -5,13 +5,15 @@ description: "Platforms and SDKs"
 
 ## Only .NET 6+? Why not .NET Framework 3.5?
 
-Eventuous uses the latest features of C#, like records and advanced pattern matching. Therefore, we rely on compiler versions which support C# 11.
+Eventuous uses the latest features of C#, like records and advanced pattern matching. Therefore, we rely on compiler versions which supports C# 11.
 
 We also aim to support the current application hosting model that only got consistent and stable in .NET 6+.
 
-Eventuous supports .NET Core 3.1, but it's not a priority. Some packages only support .NET 6 and .NET 8 as they need the latest features like minimal API. Right now, Eventuous provides packages for the following runtimes:
+Eventuous supports .NET Core 3.1, but it's not a priority. Some packages only support .NET 6 and .NET 7 as they need the latest features like minimal API. Right now, Eventuous provides packages for the following runtimes:
 
+- .NET Core 3.1
 - .NET 6
-- .NET 8
+- .NET 7
+
+Targets will be added and removed when getting our of support or when new versions get released.
 
-Targets will be added and removed when getting out of support or when new versions get released.
diff --git a/docs/src/content/docs/gateway/implementation.md b/docs/src/content/docs/gateway/implementation.md
index 2ff1d2fc0..90b0a96b8 100644
--- a/docs/src/content/docs/gateway/implementation.md
+++ b/docs/src/content/docs/gateway/implementation.md
@@ -2,7 +2,7 @@
 title: "Implementation"
 description: "Implementing the Gateway"
 sidebar:
-  order: 10
+  order: 1
 ---
 
 Gateway is a ready-made Eventuous construct that needs other components to work properly (subscription and producer at least). Any of subscription and producer type provided by Eventuous, as well as custom ones, can be used in a gateway.
@@ -62,11 +62,11 @@ record GatewayMessage<TProduceOptions>(
 
 There's no other component to implement for getting a working gateway. You need to register a gateway using one subscription, one producer, and one transformation function or class.
 
-To register a gateway, use one of the `AddGateway` methods. For example, the sample application uses this gateway registration for publishing integration events to EventStoreDB integration stream:
+To register a gateway, use one of the `AddGateway` methods. For example, the sample application uses this gateway registration for publishing integration events to KurrentDB integration stream:
 
 ```csharp
 services
-    .AddGateway<AllStreamSubscription, AllStreamSubscriptionOptions, EventStoreProducer>(
+    .AddGateway<AllStreamSubscription, AllStreamSubscriptionOptions, KurrentDBProducer>(
         "IntegrationSubscription",
         PaymentsGateway.Transform
     );
diff --git a/docs/src/content/docs/gateway/index.mdx b/docs/src/content/docs/gateway/index.mdx
index 0a4f5a37f..92d84b607 100644
--- a/docs/src/content/docs/gateway/index.mdx
+++ b/docs/src/content/docs/gateway/index.mdx
@@ -1,8 +1,6 @@
 ---
 title: "Gateway"
 description: "Event gateway copies events between databases and brokers"
-sidebar:
-  order: 80
 ---
 
 An event gateway is an engine to bridge Event Sourcing with Event-Driven Architecture (EDA). When you store events to an [event store](../persistence/event-store), you can use an event gateway to receive stored events, transform them, and distribute downstream using different transport.
diff --git a/docs/src/content/docs/infra/azure-service-bus.md b/docs/src/content/docs/infra/azure-service-bus.md
new file mode 100644
index 000000000..05819ba0d
--- /dev/null
+++ b/docs/src/content/docs/infra/azure-service-bus.md
@@ -0,0 +1,132 @@
+---
+title: "Azure Service Bus"
+description: "Producers and subscriptions for Azure Service Bus"
+sidebar:
+  order: 7
+---
+
+[Azure Service Bus](https://learn.microsoft.com/en-us/azure/service-bus-messaging/) is a fully managed enterprise message broker with message queues and publish-subscribe topics. Eventuous supports Azure Service Bus as both a [producer](../../producers) and a [subscription](../../subscriptions/subs-concept) target using the `Eventuous.Azure.ServiceBus` package.
+
+## Producer
+
+The Azure Service Bus producer publishes messages to a queue or topic.
+
+### Configuration
+
+The producer requires an Azure `ServiceBusClient` instance registered in the DI container:
+
+```csharp
+builder.Services.AddSingleton(new ServiceBusClient(connectionString));
+```
+
+Then register the producer with its options:
+
+```csharp
+builder.Services.AddProducer<ServiceBusProducer, ServiceBusProducerOptions>(
+    options => options.QueueOrTopicName = "my-topic"
+);
+```
+
+Producer options:
+
+| Option             | Description                                          | Default |
+|--------------------|------------------------------------------------------|---------|
+| `QueueOrTopicName` | Target queue or topic name (required)                | —       |
+| `SenderOptions`    | Azure SDK `ServiceBusSenderOptions` for advanced tuning | `null`  |
+| `AttributeNames`   | Customizable message attribute name mapping          | defaults |
+
+### Produce options
+
+When producing messages, you can supply per-message options using `ServiceBusProduceOptions`:
+
+| Option             | Description                                              |
+|--------------------|----------------------------------------------------------|
+| `Subject`          | Message subject                                          |
+| `To`               | Forward-to address                                       |
+| `ReplyTo`          | Reply-to address                                         |
+| `SessionId`        | Session id for session-enabled queues/topics             |
+| `ReplyToSessionId` | Reply-to session id                                      |
+| `TimeToLive`       | Message time-to-live, default is `TimeSpan.MaxValue`     |
+
+Message metadata is mapped to Azure Service Bus application properties. The attribute names used for standard properties (message type, stream name, correlation id, etc.) can be customized via `ServiceBusMessageAttributeNames`.
+
+## Subscriptions
+
+Eventuous supports consuming messages from Azure Service Bus queues and topics.
+
+### Configuration
+
+Register a subscription using `AddSubscription`:
+
+```csharp
+builder.Services.AddSubscription<ServiceBusSubscription, ServiceBusSubscriptionOptions>(
+    "PaymentsIntegration",
+    b => b
+        .Configure(cfg => cfg.QueueOrTopic = new Queue("payments-queue"))
+        .AddEventHandler<PaymentsHandler>()
+);
+```
+
+The `QueueOrTopic` property determines the source of messages. Three options are available:
+
+| Type                   | Description                                                       |
+|------------------------|-------------------------------------------------------------------|
+| `Queue(name)`          | Subscribe to a queue                                              |
+| `Topic(name)`          | Subscribe to a topic using the subscription id as the subscription name |
+| `TopicAndSubscription(topic, subscription)` | Subscribe to a topic with an explicit subscription name |
+
+Examples:
+
+```csharp
+// Queue subscription
+cfg.QueueOrTopic = new Queue("my-queue");
+
+// Topic subscription (uses subscription id as the subscription name)
+cfg.QueueOrTopic = new Topic("my-topic");
+
+// Topic subscription with explicit subscription name
+cfg.QueueOrTopic = new TopicAndSubscription("my-topic", "my-subscription");
+```
+
+### Subscription options
+
+| Option                    | Description                                                  |
+|---------------------------|--------------------------------------------------------------|
+| `QueueOrTopic`            | Queue or topic to subscribe to (required)                    |
+| `ProcessorOptions`        | Azure SDK `ServiceBusProcessorOptions` for standard processing |
+| `SessionProcessorOptions` | Enable session-based processing (see below)                  |
+| `AttributeNames`          | Message attribute name mapping                               |
+| `ErrorHandler`            | Custom error handling delegate                               |
+
+### Session support
+
+Azure Service Bus supports [sessions](https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-sessions) for ordered message processing within a session group. To enable session-based processing, configure `SessionProcessorOptions`:
+
+```csharp
+builder.Services.AddSubscription<ServiceBusSubscription, ServiceBusSubscriptionOptions>(
+    "OrderProcessing",
+    b => b
+        .Configure(cfg => {
+            cfg.QueueOrTopic = new Queue("orders-session-queue");
+            cfg.SessionProcessorOptions = new ServiceBusSessionProcessorOptions {
+                MaxConcurrentSessions = 8
+            };
+        })
+        .AddEventHandler<OrderHandler>()
+);
+```
+
+When `SessionProcessorOptions` is set, the subscription uses `ServiceBusSessionProcessor` instead of the standard `ServiceBusProcessor`. This ensures messages with the same `SessionId` are processed in order.
+
+To set the session id when producing messages, use `ServiceBusProduceOptions.SessionId`.
+
+### Error handling
+
+By default, errors are logged. You can override this by providing a custom `ErrorHandler` delegate on the subscription options:
+
+```csharp
+cfg.ErrorHandler = args => {
+    logger.LogError(args.Exception, "Service Bus error");
+    return Task.CompletedTask;
+};
+```
diff --git a/docs/src/content/docs/infra/esdb.md b/docs/src/content/docs/infra/esdb.md
index 0f569b08b..24472479c 100644
--- a/docs/src/content/docs/infra/esdb.md
+++ b/docs/src/content/docs/infra/esdb.md
@@ -1,26 +1,26 @@
 ---
-title: "EventStoreDB"
-description: "EventStoreDB is a database for event-sourced applications"
+title: "KurrentDB"
+description: "KurrentDB is a database for event-sourced applications"
 sidebar:
   order: 1
 ---
 
-Eventuous uses [EventStoreDB][1] as the default event store. It's a great product, and we're happy to provide first-class support for it. It's also a great product for learning about Event Sourcing and CQRS.
+Eventuous uses [KurrentDB][1] as the default event store. It's a great product, and we're happy to provide first-class support for it. It's also a great product for learning about Event Sourcing and CQRS.
 
-Below, you can find Eventuous components that are implemented for EventStoreDB. 
+Below, you can find Eventuous components that are implemented for KurrentDB.
 
 :::tip
-Remember to check [Event Store Cloud](https://www.eventstore.com/event-store-cloud).
+Remember to check [Kurrent Cloud](https://kurrent.io/cloud).
 :::
 
 ## Events persistence
 
-The `EsdbEventStore` is an implementation of `IEventStore` interface. It uses the EventStoreDB gRPC client, so the legacy TCP protocol isn't supported. Therefore, Eventuous only works with EventStoreDB 20+, which has gRPC support.
+The `KurrentDBEventStore` is an implementation of `IEventStore` interface. It uses the KurrentDB gRPC client, so the legacy TCP protocol isn't supported. Therefore, Eventuous only works with KurrentDB 20+, which has gRPC support.
 
-The easiest way to use it is to register it in the DI container. As `EsdbEventStore` needs an EventStoreDB client as a dependency, you'd need to register the client first. The client package has DI registration extensions that allow you to register the client using a single line of code:
+The easiest way to use it is to register it in the DI container. As `KurrentDBEventStore` needs a KurrentDB client as a dependency, you'd need to register the client first. The client package has DI registration extensions that allow you to register the client using a single line of code:
 
 ```csharp
-services.AddEventStoreClient(connectionString);
+services.AddKurrentDBClient(connectionString);
 ```
 
 The connection string usually comes from the application configuration. When running locally using Docker, you might use a connection string like:
@@ -29,19 +29,19 @@ The connection string usually comes from the application configuration. When run
 var connectionString = "esdb://localhost:2113?tls=false";
 ```
 
-When running in production, you'd use a secure connection string, which contains a username and password. You can find more information about connection strings in the [EventStoreDB documentation][3].
+When running in production, you'd use a secure connection string, which contains a username and password. You can find more information about connection strings in the [KurrentDB documentation][3].
 
-Further, you need to tell Eventuous to use the `EsdbEventStore` for its aggregate store. We have a simple extension that allows you to do that:
+Further, you need to tell Eventuous to use the `KurrentDBEventStore` for its aggregate store. We have a simple extension that allows you to do that:
 
 ```csharp
-services.AddEventStore<EsdbEventStore>();
+services.AddEventStore<KurrentDBEventStore>();
 ```
 
-When that's done, Eventuous would persist aggregates using EventStoreDB when you use the [command service](../../application/app-service).
+When that's done, Eventuous would persist aggregates using KurrentDB when you use the [command service](../../application/app-service).
 
 ## Subscriptions
 
-EventStoreDB supports multiple [subscription](../../subscriptions/subs-concept) types, and all of them are supported by Eventuous. The main choice you'd need to make is to use [catch-up][4] or [persistent subscription][5].
+KurrentDB supports multiple [subscription](../../subscriptions/subs-concept) types, and all of them are supported by Eventuous. The main choice you'd need to make is to use [catch-up][4] or [persistent subscription][5].
 
 ### All stream subscription
 
@@ -56,7 +56,7 @@ For registering a subscription to `$all` stream, use `AddSubscription<AllStreamS
 ```csharp
 builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
     "BookingsProjections",
-    b => b
+    builder => builder
         .AddEventHandler<BookingStateProjection>()
         .AddEventHandler<MyBookingsProjection>()
 );
@@ -70,7 +70,7 @@ Subscription options for `AllStreamSubscription` are defined in `AllStreamSubscr
 | `ThrowOnError`       | If `true`, an exception will be thrown if the subscription fails, otherwise the subscription continues to run. Default is `false`.                                                                                                                                 |
 | `EventSerilizer`     | Serializer for events, if `null` the default serializer will be used.                                                                                                                                                                                              |                                                                                                                                                                  
 | `MetadataSerilizer`  | Serializer for metadata, if `null` the default serializer will be used.                                                                                                                                                                                            |                                                                                
-| `Credentials`        | EventStoreDB user credentials. If not specified, the credentials specified in the `EventStoreClientSettings` will be used.                                                                                                                                         |                                                                              
+| `Credentials`        | KurrentDB user credentials. If not specified, the credentials specified in the `KurrentDBClientSettings` will be used.                                                                                                                                         |                                                                              
 | `ResolveLinkTos`     | If `true`, the subscription will automatically resolve the event link to the event that caused the event. Default is `false`.                                                                                                                                      |
 | `ConcurrencyLimit`   | Maximum number of events to be processed in parallel. Default is `1`.                                                                                                                                                                                              |                                                                                             
 | `EventFilter`        | Filter for events, if `null`, the subscription will filter out system events.                                                                                                                                                                                      |                                                                                                                                                                         
@@ -83,7 +83,7 @@ Subscription options for `AllStreamSubscription` are defined in `AllStreamSubscr
 ```csharp
 builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
     "BookingsProjections",
-    b => b
+    builder => builder
         .UseCheckpointStore<MongoCheckpointStore>()
         .AddEventHandler<BookingStateProjection>()
         .AddEventHandler<MyBookingsProjection>()
@@ -100,7 +100,7 @@ Here is an example of using `AllStreamSubscription` with `ConcurrencyLimit` and
 var partitionCount = 2;
 builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
     "BookingsProjections",
-    b => b
+    builder => builder
         .Configure(cfg => cfg.ConcurrencyLimit = partitionCount)
         .AddEventHandler<BookingStateProjection>()
         .AddEventHandler<MyBookingsProjection>()
@@ -129,7 +129,7 @@ Although subscribing to `$all` using [`AllStreamSubscription`](#all-stream-subsc
 
 For example, you can subscribe to the `$ce-Booking` stream to project all events for all the aggregates of type `Booking`, and create some representation of the state of the aggregate in a queryable store.
 
-Another scenario is to subscribe to an integration stream, when you use EventStoreDB as a backend for a messaging system.
+Another scenario is to subscribe to an integration stream, when you use KurrentDB as a backend for a messaging system.
 
 For that purpose you can use the `StreamSubscription` class.
 
@@ -138,11 +138,11 @@ For registering a subscription to a single stream, use `AddSubscription<StreamSu
 ```csharp
 builder.Services.AddSubscription<StreamSubscription, StreamSubscriptionOptions>(
     "BookingsStateProjections",
-    b => b
+    builder => builder
         .Configure(cfg => {
-            cfg.StreamName = new StreamName("$ce-Booking");
+            cfg.StreamName = "$ce-Booking";
             cfg.ResolveLinkTos = true;
-        })
+        )
         .AddEventHandler<BookingStateProjection>()
 );
 ```
@@ -156,7 +156,7 @@ Subscription options for `StreamSubscription` are defined in `StreamSubscription
 | `ThrowOnError`       | If `true`, an exception will be thrown if the subscription fails, otherwise the subscription continues to run. Default is `false`. |
 | `EventSerilizer`     | Serializer for events, if `null` the default serializer will be used.                                                              |
 | `MetadataSerilizer`  | Serializer for metadata, if `null` the default serializer will be used.                                                            |
-| `Credentials`        | EventStoreDB user credentials. If not specified, the credentials specified in the `EventStoreClientSettings` will be used.         |
+| `Credentials`        | KurrentDB user credentials. If not specified, the credentials specified in the `KurrentDBClientSettings` will be used.         |
 | `ResolveLinkTos`     | If `true`, the subscription will automatically resolve the event link to the event that caused the event. Default is `false`.      |
 | `IgnoreSystemEvents` | Set to true to ignore system events. Default is `true`.                                                                            |
 | `ConcurrencyLimit`   | Maximum number of events to be processed in parallel. Default is `1`.                                                              |
@@ -184,16 +184,16 @@ Read more about concurrent event processing on the [all stream subscription](#co
 ### Persistent subscriptions
 
 :::caution[Ordered events]
-EventStoreDB persistent subscriptions do not guarantee ordered event processing. Therefore, we only recommend using them for integration purposes (reactions).
+KurrentDB persistent subscriptions do not guarantee ordered event processing. Therefore, we only recommend using them for integration purposes (reactions).
 :::
 
 :::note
-Persistent subscription to $all stream is only supported from EventStoreDB version 21.10.0.
+Persistent subscription to $all stream is only supported from KurrentDB version 21.10.0.
 :::
 
 Unlike catch-up subscriptions, persistent subscriptions are fully managed by the database server. It is also possible to have multiple consumers for the same subscription, and the events will be distributed between them. The server also manages retries when a consumer fails to acknowledge the event. Because of the retries, batched delivery, and multiple consumers, persistent subscriptions don't guarantee ordered event processing.
 
-Read more about persistent subscriptions in the [EventStoreDB documentation](https://developers.eventstore.com/server/v21.10/persistent-subscriptions.html).
+Read more about persistent subscriptions in the [KurrentDB documentation](https://docs.kurrent.io/server/latest/features/persistent-subscriptions.html).
 
 There are some operations that must be completed before a persistent subscription starts working, In particular, the consumer group must be created on the server before a consumer can start consuming events. Eventuous implicitly creates a consumer group if necessary. The consumer group name is the same as the subscription id.
 
@@ -204,7 +204,7 @@ Here's how you set up a persistent subscription to a single stream:
 ```csharp
 builder.Services.AddSubscription<StreamPersistentSubscription, StreamPersistentSubscriptionOptions>(
     "PaymentIntegration",
-    b => b
+    builder => builder
         .Configure(x => x.StreamName = PaymentsIntegrationHandler.Stream)
         .AddEventHandler<PaymentsIntegrationHandler>()
 );
@@ -215,7 +215,7 @@ When setting up a persistent subscription to the `$all` stream, you don't need t
 ```csharp
 builder.Services.AddSubscription<AllPersistentSubscription, AllPersistentSubscriptionOptions>(
     "CrossAggregateIntegration",
-    b=> b.AddEventHandler<CrossAggregateIntegrationHandler>()
+    builder => builder.AddEventHandler<CrossAggregateIntegrationHandler>()
 );
 ```
 
@@ -223,13 +223,13 @@ There's no need to use a checkpoint store as persistent subscription checkpoint
 
 ## Producer
 
-In a prototype or small-scale production application, you can use EventStoreDB as a message broker. In that case, you can use the `EventStoreProducer` to publish events to the database. Unlike the aggregate store, [producers](../../producers) allow publishing events that aren't necessarily domain events.
+In a prototype or small-scale production application, you can use KurrentDB as a message broker. In that case, you can use the `KurrentDBProducer` to publish events to the database. Unlike the aggregate store, [producers](../../producers) allow publishing events that aren't necessarily domain events.
 
-You can then register the `EventStoreProducer` in the DI container. As the producer needs the `EventStoreClient` or `EventStoreClientSettings` as a dependency, you need to register those as well.
+You can then register the `KurrentDBProducer` in the DI container. As the producer needs the `KurrentDBClient` or `KurrentDBClientSettings` as a dependency, you need to register those as well.
 
 ```csharp
-builder.Services.AddEventStoreClient("esdb://localhost:2113?tls=false");
-builder.Services.AddEventProducer<EventStoreProducer>();
+builder.Services.AddKurrentDBClient("esdb://localhost:2113?tls=false");
+builder.Services.AddProducer<KurrentDBProducer>();
 ```
 
 To produce an event, the producer needs a stream name, a message, and (optionally) the message metadata:
@@ -249,8 +249,8 @@ var messages = events.Select(x => new ProducedMessage(x, new Metadata()));
 await producer.Produce("test-stream", messages);
 ```
 
-[1]: https://eventstore.com
-[2]: https://www.eventstore.com/event-store-cloud
-[3]: https://developers.eventstore.com/clients/grpc/
-[4]: https://developers.eventstore.com/clients/grpc/subscriptions.html
-[5]: https://developers.eventstore.com/clients/grpc/persistent-subscriptions.html
+[1]: https://kurrent.io
+[2]: https://kurrent.io/cloud
+[3]: https://docs.kurrent.io/clients/grpc/
+[4]: https://docs.kurrent.io/clients/grpc/subscriptions.html
+[5]: https://docs.kurrent.io/clients/grpc/persistent-subscriptions.html
diff --git a/docs/src/content/docs/infra/mongodb.md b/docs/src/content/docs/infra/mongodb.md
index 0c2f69d37..5fdd9f5d4 100644
--- a/docs/src/content/docs/infra/mongodb.md
+++ b/docs/src/content/docs/infra/mongodb.md
@@ -245,4 +245,4 @@ public class MyBookingsProjection : MongoProjection<MyBookings> {
 
 MongoDB projection is an event handler, so it can be added to a subscription using the `AddEventHandler` extension of the subscription builder.
 
-You can find examples of adding handlers to subscriptions in the [subscription documentation](../../subscriptions/sub-base/#registration).
+You can find examples of adding handlers to subscriptions in the [subscription documentation](../../subscriptions/sub-base#registration).
diff --git a/docs/src/content/docs/infra/mssql.md b/docs/src/content/docs/infra/mssql.md
index 9e5d8a21f..4cb45129e 100644
--- a/docs/src/content/docs/infra/mssql.md
+++ b/docs/src/content/docs/infra/mssql.md
@@ -29,7 +29,7 @@ For subscriptions, Eventuous adds a table called `Checkpoints` that stores the l
 ## Event persistence
 
 Before using SQL Server as an event store, you need to register the SQL Server-based event store implementation.
-For that to work, you'd also need to register an SQL Sever connection detail used to create connections to the database.
+For that to work, you'd also need to register an SQL Server connection detail used to create connections to the database.
 Eventuous provides a few overloads for `AddEventuousSqlServer` registration extension to do that.
 
 One way to register the connection details is to provide a connection string and, optionally, the schema name:
@@ -82,14 +82,14 @@ Both subscription types use continuous polling to check for new events.
 
 ### Registering subscriptions
 
-Registering a global log subscription is similar to [EventStoreDB](../esdb#all-stream-subscription). The only difference is the subscription and the options types:
+Registering a global log subscription is similar to [KurrentDB](../esdb#all-stream-subscription). The only difference is the subscription and the options types:
 
 ```csharp title="Program.cs"
 builder.Services.AddSubscription<SqlServerAllStreamSubscription, SqlServerAllStreamSubscriptionOptions>(
     "BookingsProjections",
     b => b
         .AddEventHandler<BookingStateProjection>()
-        .AddEventHandler<MyBookingsProjection>();
+        .AddEventHandler<MyBookingsProjection>()
 );
 ```
 
@@ -100,7 +100,7 @@ builder.Services.AddSubscription<SqlServerStreamSubscription, SqlServerStreamSub
     "StreamSubscription",
     b => b
         .Configure(x => x.StreamName = "my-stream")
-        .AddEventHandler<StreamSubscriptionHander>()
+        .AddEventHandler<StreamSubscriptionHandler>()
 );
 ```
 
@@ -170,8 +170,8 @@ You can project the `BookingImported` event to this table using a simple project
 public class ImportingBookingsProjector : SqlServerProjector {
     public ImportingBookingsProjector(SqlServerConnectionOptions options) : base(options) {
         var insert = $"""
-                      INSERT INTO {schemaInfo.Schema}.Bookings 
-                      (BookingId, CheckinDate, Price) 
+                      INSERT INTO {options.Schema}.Bookings
+                      (BookingId, CheckinDate, Price)
                       VALUES (@BookingId, @CheckinDate, @Price)
                       """;
 
@@ -198,7 +198,7 @@ builder.Services.AddSubscription<SqlServerAllStreamSubscription, SqlServerAllStr
     "ImportedBookingsProjections",
     b => b
         .UseCheckpointStore<SqlServerCheckpointStore>()
-        .AddEventHandler<ImportingBookingsProjector>();
+        .AddEventHandler<ImportingBookingsProjector>()
 );
 ```
 
@@ -208,4 +208,3 @@ At this moment, there is no way to use different checkpoint store options for ea
 :::
 
 Note that the `insert` operation in the projection is not idempotent, so if the event is processed twice because there was a failure, the projector will throw an exception. It would not be an issue when the subscription uses the default setting that tells it not to stop when the handler fails. If you want to ensure that failures force the subscription to throw, you can change the subscription option `ThrowOnError` to `true`, and make the operation idempotent by using "insert or update".
-Microsoft SQL Server is a popular choice for storing queryable application data. Many organizations that use .NET as their preferred stack also use SQL Server.
diff --git a/docs/src/content/docs/infra/postgres.md b/docs/src/content/docs/infra/postgres.md
index 10ef3081f..c1ea9ce89 100644
--- a/docs/src/content/docs/infra/postgres.md
+++ b/docs/src/content/docs/infra/postgres.md
@@ -7,7 +7,7 @@ sidebar:
 
 PostgreSQL is a powerful, open source object-relational database system with over 30 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance. [source](https://www.postgresql.org/).
 
-Eventuous supports Postgres as an event store and also allows subscribing to the global event log and to individual streams using catch-up subscriptions.
+Eventuous supports Postgres as an event store, and also allows subscribing to the global event log and to individual streams using catch-up subscriptions.
 
 ## Data model
 
@@ -30,62 +30,59 @@ For subscriptions, Eventuous adds a table called `checkpoints` that stores the l
 
 ## Event persistence
 
-Before using Postgres as an event store, you need to register the Postgres-based event store implementation.
-For that to work, you'd also need to register a Postgres data source, which is used to create connections to the database.
-Eventuous provides a few overloads for `AddEventuousPostgres` registration extension to do that.
-
-One way to register the data source is to provide a connection string and, optionally, the schema name:
+Usually, you just need to register the aggregate store that uses the Postgres event store. For that to work, you'd also need to register a Postgres connection factory, which is used to create connections to the database.
 
 ```csharp title="Program.cs"
-builder.Services.AddEventuousPostgres(connectionString, "mySchema");
+// Local connection factory function
+NpgsqlConnection GetConnection() => new(connectionString);
+
+builder.Services.AddSingleton((GetPostgresConnection)GetConnection);
+builder.Services.AddAggregateStore<PostgresStore>();
 ```
 
-If the schema name is not provided, the default schema name (`eventuous`) will be used.
+For the newer NpgSql driver (v7+), you can use the `NpgsqlDataSourceBuilder`:
+
+```csharp title="Program.cs"
+var ds = new NpgsqlDataSourceBuilder(connectionString).Build();
+NpgsqlConnection GetConnection() => ds.CreateConnection();
+builder.Services.AddSingleton(GetConnection());
+builder.Services.AddAggregateStore<PostgresStore>();
+```
 
-Another way to register the data source is by using configuration options. For example, you can add the following to the settings file:
+You can also override the default schema by configuring the store options:
 
-```json title="appSettings.json"
+```json title="appsettings.json"
 {
   "PostgresStore": {
-    "Schema": "mySchema",
-    "ConnectionString": "Host=localhost;Username=postgres;Password=secret;Database=mydb;",
-    "InitializeDatabase": true
+    "Schema": "my-schema"
   }
 }
 ```
 
-Then, use the configuration section to register the data source:
-
 ```csharp title="Program.cs"
-builder.Services.AddEventuousPostgres(
+builder.Services.Configure<PostgresStoreOptions>(
     builder.Configuration.GetSection("PostgresStore")
 );
 ```
 
-The `InitializeDatabase` setting tells Eventuous if it needs to create the schema. If you create the schema in a separate migration application, set this setting to `false`. If the schema cannot be found, and the `InitializeDatabase` setting is set to `false`, the application will fail to start.
+When that's done, Eventuous would persist aggregates in Postgres when you use the [command service](../../application/app-service).
 
-Next, you need to register the Postgres event store:
-
-```csharp
-builder.Services.AddEventStore<PostgresStore>();
-```
-
-When that's done, Eventuous will use Postgres for persistence in command services.
+At this moment, the Postgres event store implementation doesn't support stream truncation.
 
 ## Subscriptions
 
 Eventuous supports two types of subscriptions to Postgres: global and stream. The global subscription is a catch-up subscription, which means that it reads all events from the beginning of the event log. The stream subscription is also a catch-up subscription, but it only reads events from a specific stream.
 
-Both subscription types use continuous polling to check for new events. We don't use the notification feature of Postgres.
+Both subscription types use continuous polling to check for new events. We don't use the notifications feature of Postgres database.
 
 ### Registering subscriptions
 
-Registering a global log subscription is similar to [EventStoreDB](../esdb#all-stream-subscription). The only difference is the subscription and the options types:
+Registering a global log subscription is similar to [KurrentDB](../esdb#all-stream-subscription). The only difference is the subscription and the options types:
 
 ```csharp title="Program.cs"
 builder.Services.AddSubscription<PostgresAllStreamSubscription, PostgresAllStreamSubscriptionOptions>(
     "BookingsProjections",
-    b => b
+    builder => builder
         .AddEventHandler<BookingStateProjection>()
         .AddEventHandler<MyBookingsProjection>();
 );
@@ -96,28 +93,18 @@ When you register a subscription to a single stream, you need to configure the s
 ```csharp title="Program.cs"
 builder.Services.AddSubscription<PostgresStreamSubscription, PostgresStreamSubscriptionOptions>(
     "StreamSubscription",
-    b => b
+    builder => builder
         .Configure(x => x.StreamName = "my-stream")
         .AddEventHandler<StreamSubscriptionHander>()
 );
 ```
 
-As subscriptions use a Postgres data source for opening the connection, there's no need to register additional dependencies apart from calling `AddEventuousPostgres` as described in [event persistence](#event-persistence) section above.
-
 ### Checkpoint store
 
 Catch-up subscriptions need a [checkpoint](../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, and it will be used for all subscriptions in the application.
 
 Remember to store the checkpoint in the same database as the read model. For example, if you use Postgres as an event store, and project events to read models in MongoDB, you need to use the `MongoCheckpointStore`. Eventuous also has a checkpoint store implementation for Postgres (`PostgresCheckpointStore`), which you can use if you project events to Postgres.
 
-When using the Postgres checkpoint store, you can register it using a dedicated extension function:
-
-```csharp
-builder.Services.AddPostgresCheckpointStore();
-```
-
-This registration function will use the schema name provided when you register the data source using `AddEventuousPostgres`.
-
 ### Projections
 
 You can use Postgres both as an event store and as a read model store. In that case, you can use the same connection factory for both the event store, the checkpoint store, and the projector.
@@ -138,7 +125,7 @@ You can project the `BookingImported` event to this table using a simple project
 
 ```csharp title="ImportingBookingsProjector.cs"
 public class ImportingBookingsProjector : PostgresProjector {
-    public ImportingBookingsProjector(NpgsqlDataSource dataSource) : base(dataSource) {
+    public ImportingBookingsProjector(GetPostgresConnection getConnection) : base(getConnection) {
         const string insert = @"insert into myschema.bookings 
             (booking_id, checkin_date, price) 
             values (@booking_id, @checkin_date, @price)";
@@ -157,21 +144,17 @@ public class ImportingBookingsProjector : PostgresProjector {
 }
 ```
 
-There, `Project` is a small helper function that creates a command from a given connection, sets the command type to `Text`, assigns the given SQL statement, and adds parameters to the command. It then returns the command, so it can be executed by the projector.
+There, `Project` is a small helper function that creates a command from a given connection, sets the command type to `Text`, assigns the given SQL statement, and adds the given parameters to the command. It then returns the command, so it can be executed by the projector.
 
 You can then register the projector as a subscription handler:
 
 ```csharp title="Program.cs"
 builder.Services.AddSubscription<PostgresAllStreamSubscription, PostgresAllStreamSubscriptionOptions>(
     "ImportedBookingsProjections",
-    b => b
+    builder => builder
         .UseCheckpointStore<PostgresCheckpointStore>()
         .AddEventHandler<ImportingBookingsProjector>();
 );
 ```
 
-:::note
-You only need to explicitly specify the subscription checkpoint store with `UseCheckpointStore` if your application uses different checkpoint stores for different subscriptions.
-At this moment, there is no way to use different checkpoint store options for each subscription in the same application, they will all use the same `PostgresCheckpointStoreOptions`.
-:::
-
+Note that the `insert` operation in the projection is not idempotent, so if the event is processed twice because there was a failure, the projector will throw an exception. It would not be an issue when the subscription uses the default setting that tells it not to stop when the handler fails. If you want to ensure that failures force the subscription to throw, you can change the subscription option `ThroOnError` to `true`, and make the operation idempotent by using "insert or update".
diff --git a/docs/src/content/docs/infra/pubsub.md b/docs/src/content/docs/infra/pubsub.md
index b70ff7050..1430c1a65 100644
--- a/docs/src/content/docs/infra/pubsub.md
+++ b/docs/src/content/docs/infra/pubsub.md
@@ -51,18 +51,19 @@ Eventuous allows you to consume messages from Google Pub/Sub, which are publishe
 Normally, you'd add the subscription to the service collection using `AddSubscription` extension method, as any other Eventuous subscription.
 
 ```csharp
-builder.Services.AddSubscription<GooglePubSubSubscription, PubSubSubscriptionOptions>(
-    "pubsub-subscription",
-    b => b
-        .Configure(
-            x => {
-                x.ProjectId          = "my-gcp-project";
-                x.TopicId            = "my-topic";
-                x.CreateSubscription = true;
-            }
-        )
-        .AddEventHandler<TestHandler>()
-);
+services
+    .AddSubscription<GooglePubSubSubscription, PubSubSubscriptionOptions>(
+        "pubsub-subscription",
+        builder => builder
+            .Configure(
+                x => {
+                    x.ProjectId          = "my-gcp-project";
+                    x.TopicId            = "my-topic";
+                    x.CreateSubscription = true;
+                }
+            )
+            .AddEventHandler<TestHandler>()
+    );
 ```
 
 Similarly to the producer, the Eventuous subscription can create a Pub/Sub subscription if it does not exist. Creating a subscription is a one-time operation, so you can set this option to `false` after the subscription is created. Often, you would have a separate process that creates topics and subscriptions, so the `CreateSubscription` option is set to `false` by default. 
diff --git a/docs/src/content/docs/infra/rabbitmq.md b/docs/src/content/docs/infra/rabbitmq.md
index 1e0535b58..bf5bd372a 100644
--- a/docs/src/content/docs/infra/rabbitmq.md
+++ b/docs/src/content/docs/infra/rabbitmq.md
@@ -7,8 +7,8 @@ sidebar:
 
 ## Introduction
 
-RabbitMQ is a popular message broker, and it can serve as a great integration infrastructure for communicating 
-between services. Eventuous supports using RabbitMQ messaging with [producers](../../producers) for producing messages 
+RabbitMQ is a popular message broker, and it can serve as a great integration infrastructure for communicating
+between services. Eventuous supports using RabbitMQ messaging with [producers](../../producers) for producing messages
 and [subscriptions](../../subscriptions/subs-concept) for consuming messages.
 
 Eventuous producer for RabbitMQ publishes messages to _exchanges_.
@@ -33,7 +33,7 @@ builder.Services.AddSingleton(
     new ConnectionFactory {
         Uri = new Uri(rabbitMqConnectionString)
     }
-); 
+);
 ```
 
 When that's done, you can register the producer by using `AddProducer` extension provided by Eventuous:
@@ -78,7 +78,7 @@ Eventuous supports consuming messages from RabbitMQ using [subscriptions](../../
 
 ### Configuration
 
-As any other subscription, it can be added to the Di container using `AddSubscription` extension:
+As any other subscription, it can be added to the DI container using `AddSubscription` extension:
 
 ```csharp
 builder.Services.AddSubscription<RabbitMqSubscription, RabbitMqSubscriptionOptions>(
@@ -93,7 +93,7 @@ The `Exchange` configuration property is mandatory as the subscription needs to
 
 For consuming messages, the subscription needs a queue bound to the specified exchange. By default, the subscription id is used as the queue name. You can override the queue name by specifying an alternative value using `QueueOptions.Queue` property of the subscription options.
 
-Besides the queue name, it's possible to configure the subscription with RabbitQ-specific parameters. Those include queue options, exchange options, and binding options. Eventuous provides default values for all those, so usually you would not need to change those. One option that likely should be overridden is the concurrency limit value, which is set to `1` by default. As RabbitMQ doesn't guarantee message ordering anyway, you can speed up message processing by increasing the concurrency limit, so the subscription can consume messages in parallel. Eventuous will also adjust the prefetch count to accommodate for increased number of consumers, if necessary.
+Besides the queue name, it's possible to configure the subscription with RabbitMQ-specific parameters. Those include queue options, exchange options, and binding options. Eventuous provides default values for all those, so usually you would not need to change those. One option that likely should be overridden is the concurrency limit value, which is set to `1` by default. As RabbitMQ doesn't guarantee message ordering anyway, you can speed up message processing by increasing the concurrency limit, so the subscription can consume messages in parallel. Eventuous will also adjust the prefetch count to accommodate for increased number of consumers, if necessary.
 
 As mentioned previously, RabbitMQ messages are published to an exchange and consumed from a queue bound to that exchange. When the subscription starts, it makes sure that both the exchange and the queue exist, and the queue is bound to the exchange. If you start producing messages to an exchange created by the producer before starting the subscription at least once, and there's no queue and binding created upfront, those messages will be dropped. As long as the exchange has a binding to a subscription queue, the messages will be kept in the queue until consumed. Therefore, we recommend starting the subscription before producing messages.
 
@@ -125,7 +125,7 @@ For configuring the subscription queue, the following options are available in `
 
 | Name         | Description                                                                       |
 |--------------|-----------------------------------------------------------------------------------|
-| `Queue`      | Overriders the default queue name, which is set to subscription id by default     |
+| `Queue`      | Overrides the default queue name, which is set to subscription id by default      |
 | `AutoDelete` | Default is `false`, so the queue will survive restarts                            |
 | `Exclusive`  | Default is `false`, change it if you want to only have a single consumer instance |
 | `Durable`    | Default is `true`, so the queue will be persisted on disk                         |
@@ -156,4 +156,4 @@ Eventuous uses a different approach where the service normally produces messages
 
 [1]: https://www.rabbitmq.com/docs/confirms#channel-qos-prefetch
 [2]: https://www.rabbitmq.com/docs/ttl#per-message-ttl-in-publishers
-[3]: https://www.rabbitmq.com/tutorials/tutorial-four-dotnet
\ No newline at end of file
+[3]: https://www.rabbitmq.com/tutorials/tutorial-four-dotnet
diff --git a/docs/src/content/docs/infra/sqlite.md b/docs/src/content/docs/infra/sqlite.md
new file mode 100644
index 000000000..d7a7c34ac
--- /dev/null
+++ b/docs/src/content/docs/infra/sqlite.md
@@ -0,0 +1,158 @@
+---
+title: "SQLite"
+description: "Supported SQLite infrastructure"
+sidebar:
+  order: 5
+---
+
+SQLite is a self-contained, serverless, zero-configuration SQL database engine. It is the most widely deployed database engine in the world. [source](https://www.sqlite.org/).
+
+Eventuous supports SQLite as an event store for embedded and local applications (desktop, mobile, CLI tools) that need event sourcing without external database dependencies. It supports catch-up subscriptions to the global event log and to individual streams, as well as projections.
+
+The SQLite implementation uses the `Microsoft.Data.Sqlite` provider and enables WAL (Write-Ahead Logging) mode by default for concurrent read access.
+
+## Data model
+
+Eventuous uses a single table to store events. The table name is `{schema}_messages`, where `{schema}` defaults to `eventuous`. In addition, another table called `{schema}_streams` is used to control the stream existence, and store the last event number for each stream. Events and metadata are stored as TEXT (JSON) columns. The table schema is as follows:
+
+```sql
+global_position INTEGER PRIMARY KEY AUTOINCREMENT,
+message_id      TEXT    NOT NULL,
+message_type    TEXT    NOT NULL,
+stream_id       INTEGER NOT NULL REFERENCES streams(stream_id),
+stream_position INTEGER NOT NULL,
+json_data       TEXT    NOT NULL,
+json_metadata   TEXT,
+created         TEXT    NOT NULL
+```
+
+Since SQLite doesn't support SQL schema namespaces, Eventuous uses a table name prefix instead (e.g. `eventuous_streams`, `eventuous_messages`).
+
+For subscriptions, Eventuous adds a table called `{schema}_checkpoints` that stores the last processed event number for each subscription.
+
+## Event persistence
+
+To register the SQLite event store, use the `AddEventuousSqlite` extension method. This registers the store, schema, and optionally initializes the database on startup:
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousSqlite(
+    "Data Source=myapp.db",
+    schema: "eventuous",
+    initializeDatabase: true
+);
+builder.Services.AddEventStore<SqliteStore>();
+```
+
+You can also configure the store using `IConfiguration`:
+
+```json title="appsettings.json"
+{
+  "SqliteStore": {
+    "ConnectionString": "Data Source=myapp.db",
+    "Schema": "eventuous",
+    "InitializeDatabase": true
+  }
+}
+```
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousSqlite(
+    builder.Configuration.GetSection("SqliteStore")
+);
+builder.Services.AddEventStore<SqliteStore>();
+```
+
+When that's done, Eventuous will persist aggregates in SQLite when you use the [command service](../../application/app-service).
+
+## Subscriptions
+
+Eventuous supports two types of subscriptions to SQLite: global and stream. The global subscription is a catch-up subscription that reads all events from the global event log. The stream subscription reads events from a specific stream only.
+
+Both subscription types use continuous polling to check for new events.
+
+### Registering subscriptions
+
+Registering a global log subscription:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqliteAllStreamSubscription, SqliteAllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    builder => builder
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>()
+);
+```
+
+When you register a subscription to a single stream, you need to configure the subscription options to specify the stream name:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqliteStreamSubscription, SqliteStreamSubscriptionOptions>(
+    "StreamSubscription",
+    builder => builder
+        .Configure(x => x.Stream = "my-stream")
+        .AddEventHandler<StreamSubscriptionHandler>()
+);
+```
+
+### Checkpoint store
+
+Catch-up subscriptions need a [checkpoint](../../subscriptions/checkpoint). You can register the SQLite checkpoint store, and it will be used for all subscriptions in the application:
+
+```csharp title="Program.cs"
+builder.Services.AddSqliteCheckpointStore();
+```
+
+The checkpoint store uses the same connection string and schema as the event store when registered via `AddEventuousSqlite`.
+
+## Projections
+
+You can use SQLite both as an event store and as a read model store. Eventuous provides a projector base class that allows you to emit SQL statements for events, and the projector will execute them.
+
+Consider the following table schema for the query model:
+
+```sql
+CREATE TABLE IF NOT EXISTS bookings (
+    booking_id   TEXT NOT NULL PRIMARY KEY,
+    checkin_date TEXT,
+    price        REAL
+);
+```
+
+You can project the `BookingImported` event to this table:
+
+```csharp title="ImportingBookingsProjector.cs"
+public class ImportingBookingsProjector : SqliteProjector {
+    public ImportingBookingsProjector(SqliteConnectionOptions connectionOptions)
+        : base(connectionOptions) {
+        const string insert = """
+            INSERT OR REPLACE INTO bookings
+                (booking_id, checkin_date, price)
+            VALUES (@booking_id, @checkin_date, @price)
+            """;
+
+        On<BookingEvents.BookingImported>(
+            (connection, ctx) =>
+                Project(
+                    connection,
+                    insert,
+                    new SqliteParameter("@booking_id", ctx.Stream.GetId()),
+                    new SqliteParameter("@checkin_date", ctx.Message.CheckIn.ToString("o")),
+                    new SqliteParameter("@price", ctx.Message.Price)
+                )
+        );
+    }
+}
+```
+
+You can then register the projector as a subscription handler:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqliteAllStreamSubscription, SqliteAllStreamSubscriptionOptions>(
+    "ImportedBookingsProjections",
+    builder => builder
+        .UseCheckpointStore<SqliteCheckpointStore>()
+        .AddEventHandler<ImportingBookingsProjector>()
+);
+```
+
+Using `INSERT OR REPLACE` makes the projection idempotent, so reprocessing events after a failure won't cause errors.
diff --git a/docs/src/content/docs/intro.mdx b/docs/src/content/docs/intro.mdx
index a96e317e9..555a504bb 100644
--- a/docs/src/content/docs/intro.mdx
+++ b/docs/src/content/docs/intro.mdx
@@ -1,11 +1,9 @@
 ---
-title: "Start here"
+title: "Introduction"
 sidebar:
-  order: 1
+  order: 0
 ---
 
-# Start here
-
 First, why would you use Eventuous instead of rolling out your own library to support Event Sourcing? From our experience, doing that is totally possible, but it's laborious, time-consuming, and prone to failure.
 
 ## Do you need it?
@@ -26,7 +24,7 @@ If you are convinced that Eventuous is the right tool for you, here are the next
   - [Application service](../application) components
   - [Subscriptions](../subscriptions/subs-concept) for event processing (like [read models](../read-models/rm-concept))
 - Check sample applications to see how Eventuous is used in practice:
-  - [EventStoreDB](https://github.com/eventuous/dotnet-sample) sample
+  - [KurrentDB](https://github.com/eventuous/dotnet-sample) sample
   - [PostgreSQL](https://github.com/eventuous/dotnet-sample-postgres) sample
 
 ## Community
@@ -37,4 +35,4 @@ Ensure you follow the [Code of Conduct](https://github.com/Eventuous/eventuous/b
 
 Eventuous is open source and licensed under the Apache 2.0 licence.
 
-Support the project by providing [sponsorships](https://github.com/sponsors/Eventuous). Eventuous has sponsor plans for both individuals and companies. You can get paid support for your projects, or just show your appreciation for the project.
\ No newline at end of file
+Support the project by providing [sponsorships](https://github.com/sponsors/Eventuous). Eventuous has sponsor plans for both individuals and companies. You can get paid support for your projects, or just show your appreciation for the project.
diff --git a/docs/src/content/docs/next/application/app-service.md b/docs/src/content/docs/next/application/app-service.md
index 3a071c130..1993d7b36 100644
--- a/docs/src/content/docs/next/application/app-service.md
+++ b/docs/src/content/docs/next/application/app-service.md
@@ -2,7 +2,7 @@
 title: "Command service"
 description: "Command service and unit of work for aggregates"
 sidebar:
-  order: 1
+  order: 10
 ---
 
 ## Concept
diff --git a/docs/src/content/docs/next/application/command-api.md b/docs/src/content/docs/next/application/command-api.md
index e0f9d4696..65842c463 100644
--- a/docs/src/content/docs/next/application/command-api.md
+++ b/docs/src/content/docs/next/application/command-api.md
@@ -2,7 +2,7 @@
 title: "Command API"
 description: "Auto-generated HTTP API for command handling"
 sidebar:
-  order: 3
+  order: 30
 ---
 
 ## Controller base
diff --git a/docs/src/content/docs/next/application/command-map.mdx b/docs/src/content/docs/next/application/command-map.mdx
index d75f3ecf1..6659d30f0 100644
--- a/docs/src/content/docs/next/application/command-map.mdx
+++ b/docs/src/content/docs/next/application/command-map.mdx
@@ -2,9 +2,9 @@
 title: "Command mapping"
 description: "Mapping contracts to domain commands"
 sidebar:
-  order: 4
+  order: 40
 ---
-import Highlight from '../../../../components/Highlight.astro';
+import Highlight from '@components/Highlight.astro';
 
 ## Motivation
 
diff --git a/docs/src/content/docs/next/application/func-service.md b/docs/src/content/docs/next/application/func-service.md
index 38f23d172..7426e869a 100644
--- a/docs/src/content/docs/next/application/func-service.md
+++ b/docs/src/content/docs/next/application/func-service.md
@@ -2,7 +2,7 @@
 title: "Functional service"
 description: "Functional command service and unit of work without aggregates"
 sidebar:
-  order: 3
+  order: 20
 ---
 
 ## Concept
@@ -139,4 +139,4 @@ builder.Services.AddFunctionalService<BookingFuncService, BookingState>();
 builder.Services.AddFunctionalService(sp => 
     new AnotherFuncService(sp.GetRequiredService<IEventStore>(), customTypeMap)
 );
-```
\ No newline at end of file
+```
diff --git a/docs/src/content/docs/next/application/index.mdx b/docs/src/content/docs/next/application/index.mdx
index 1bc4517cd..7144a9aae 100644
--- a/docs/src/content/docs/next/application/index.mdx
+++ b/docs/src/content/docs/next/application/index.mdx
@@ -1,6 +1,7 @@
 ---
 title: "Application"
 description: "Application layer and service"
+order: 1
 ---
 
 The application layer sits between the system edge (different APIs), and the domain model. It is responsible for handling commands coming from the edge.
diff --git a/docs/src/content/docs/next/infra/azure-service-bus.md b/docs/src/content/docs/next/infra/azure-service-bus.md
new file mode 100644
index 000000000..05819ba0d
--- /dev/null
+++ b/docs/src/content/docs/next/infra/azure-service-bus.md
@@ -0,0 +1,132 @@
+---
+title: "Azure Service Bus"
+description: "Producers and subscriptions for Azure Service Bus"
+sidebar:
+  order: 7
+---
+
+[Azure Service Bus](https://learn.microsoft.com/en-us/azure/service-bus-messaging/) is a fully managed enterprise message broker with message queues and publish-subscribe topics. Eventuous supports Azure Service Bus as both a [producer](../../producers) and a [subscription](../../subscriptions/subs-concept) target using the `Eventuous.Azure.ServiceBus` package.
+
+## Producer
+
+The Azure Service Bus producer publishes messages to a queue or topic.
+
+### Configuration
+
+The producer requires an Azure `ServiceBusClient` instance registered in the DI container:
+
+```csharp
+builder.Services.AddSingleton(new ServiceBusClient(connectionString));
+```
+
+Then register the producer with its options:
+
+```csharp
+builder.Services.AddProducer<ServiceBusProducer, ServiceBusProducerOptions>(
+    options => options.QueueOrTopicName = "my-topic"
+);
+```
+
+Producer options:
+
+| Option             | Description                                          | Default |
+|--------------------|------------------------------------------------------|---------|
+| `QueueOrTopicName` | Target queue or topic name (required)                | —       |
+| `SenderOptions`    | Azure SDK `ServiceBusSenderOptions` for advanced tuning | `null`  |
+| `AttributeNames`   | Customizable message attribute name mapping          | defaults |
+
+### Produce options
+
+When producing messages, you can supply per-message options using `ServiceBusProduceOptions`:
+
+| Option             | Description                                              |
+|--------------------|----------------------------------------------------------|
+| `Subject`          | Message subject                                          |
+| `To`               | Forward-to address                                       |
+| `ReplyTo`          | Reply-to address                                         |
+| `SessionId`        | Session id for session-enabled queues/topics             |
+| `ReplyToSessionId` | Reply-to session id                                      |
+| `TimeToLive`       | Message time-to-live, default is `TimeSpan.MaxValue`     |
+
+Message metadata is mapped to Azure Service Bus application properties. The attribute names used for standard properties (message type, stream name, correlation id, etc.) can be customized via `ServiceBusMessageAttributeNames`.
+
+## Subscriptions
+
+Eventuous supports consuming messages from Azure Service Bus queues and topics.
+
+### Configuration
+
+Register a subscription using `AddSubscription`:
+
+```csharp
+builder.Services.AddSubscription<ServiceBusSubscription, ServiceBusSubscriptionOptions>(
+    "PaymentsIntegration",
+    b => b
+        .Configure(cfg => cfg.QueueOrTopic = new Queue("payments-queue"))
+        .AddEventHandler<PaymentsHandler>()
+);
+```
+
+The `QueueOrTopic` property determines the source of messages. Three options are available:
+
+| Type                   | Description                                                       |
+|------------------------|-------------------------------------------------------------------|
+| `Queue(name)`          | Subscribe to a queue                                              |
+| `Topic(name)`          | Subscribe to a topic using the subscription id as the subscription name |
+| `TopicAndSubscription(topic, subscription)` | Subscribe to a topic with an explicit subscription name |
+
+Examples:
+
+```csharp
+// Queue subscription
+cfg.QueueOrTopic = new Queue("my-queue");
+
+// Topic subscription (uses subscription id as the subscription name)
+cfg.QueueOrTopic = new Topic("my-topic");
+
+// Topic subscription with explicit subscription name
+cfg.QueueOrTopic = new TopicAndSubscription("my-topic", "my-subscription");
+```
+
+### Subscription options
+
+| Option                    | Description                                                  |
+|---------------------------|--------------------------------------------------------------|
+| `QueueOrTopic`            | Queue or topic to subscribe to (required)                    |
+| `ProcessorOptions`        | Azure SDK `ServiceBusProcessorOptions` for standard processing |
+| `SessionProcessorOptions` | Enable session-based processing (see below)                  |
+| `AttributeNames`          | Message attribute name mapping                               |
+| `ErrorHandler`            | Custom error handling delegate                               |
+
+### Session support
+
+Azure Service Bus supports [sessions](https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-sessions) for ordered message processing within a session group. To enable session-based processing, configure `SessionProcessorOptions`:
+
+```csharp
+builder.Services.AddSubscription<ServiceBusSubscription, ServiceBusSubscriptionOptions>(
+    "OrderProcessing",
+    b => b
+        .Configure(cfg => {
+            cfg.QueueOrTopic = new Queue("orders-session-queue");
+            cfg.SessionProcessorOptions = new ServiceBusSessionProcessorOptions {
+                MaxConcurrentSessions = 8
+            };
+        })
+        .AddEventHandler<OrderHandler>()
+);
+```
+
+When `SessionProcessorOptions` is set, the subscription uses `ServiceBusSessionProcessor` instead of the standard `ServiceBusProcessor`. This ensures messages with the same `SessionId` are processed in order.
+
+To set the session id when producing messages, use `ServiceBusProduceOptions.SessionId`.
+
+### Error handling
+
+By default, errors are logged. You can override this by providing a custom `ErrorHandler` delegate on the subscription options:
+
+```csharp
+cfg.ErrorHandler = args => {
+    logger.LogError(args.Exception, "Service Bus error");
+    return Task.CompletedTask;
+};
+```
diff --git a/docs/src/content/docs/next/infra/esdb.md b/docs/src/content/docs/next/infra/esdb.md
index 44be2c514..24472479c 100644
--- a/docs/src/content/docs/next/infra/esdb.md
+++ b/docs/src/content/docs/next/infra/esdb.md
@@ -37,11 +37,11 @@ Further, you need to tell Eventuous to use the `KurrentDBEventStore` for its agg
 services.AddEventStore<KurrentDBEventStore>();
 ```
 
-When that's done, Eventuous would persist aggregates using KurrentDB when you use the [command service](../../../application/app-service).
+When that's done, Eventuous would persist aggregates using KurrentDB when you use the [command service](../../application/app-service).
 
 ## Subscriptions
 
-KurrentDB supports multiple [subscription](../../../subscriptions/subs-concept) types, and all of them are supported by Eventuous. The main choice you'd need to make is to use [catch-up][4] or [persistent subscription][5].
+KurrentDB supports multiple [subscription](../../subscriptions/subs-concept) types, and all of them are supported by Eventuous. The main choice you'd need to make is to use [catch-up][4] or [persistent subscription][5].
 
 ### All stream subscription
 
@@ -78,7 +78,7 @@ Subscription options for `AllStreamSubscription` are defined in `AllStreamSubscr
 
 #### Checkpoint store
 
-`AllStreamSubscription` is a catch-up subscription that is fully managed on the client side (your application), so you need to manage the [checkpoint](../../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, but in that case it will be used for all subscriptions in the application. It might be that your app has multiple subscriptions, and you want to use different checkpoint stores for each of them. In that case, you can register the checkpoint store for each subscription using `UseCheckpointStore<T>` extension of the subscription builder
+`AllStreamSubscription` is a catch-up subscription that is fully managed on the client side (your application), so you need to manage the [checkpoint](../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, but in that case it will be used for all subscriptions in the application. It might be that your app has multiple subscriptions, and you want to use different checkpoint stores for each of them. In that case, you can register the checkpoint store for each subscription using `UseCheckpointStore<T>` extension of the subscription builder
 
 ```csharp
 builder.Services.AddSubscription<AllStreamSubscription, AllStreamSubscriptionOptions>(
@@ -171,7 +171,7 @@ When subscribing to a stream that contains link events (for example, `$ce-` cate
 
 #### Checkpoint store
 
-`StreamSubscription` is a catch-up subscription that is fully managed on the client side (your application), so you need to manage the [checkpoint](../../../subscriptions/checkpoint). The checkpoint store configuration for stream subscriptions is identical to the one for the [`AllStreamSubscription`](#checkpoint-store).
+`StreamSubscription` is a catch-up subscription that is fully managed on the client side (your application), so you need to manage the [checkpoint](../../subscriptions/checkpoint). The checkpoint store configuration for stream subscriptions is identical to the one for the [`AllStreamSubscription`](#checkpoint-store).
 
 #### Concurrent event handlers
 
@@ -223,7 +223,7 @@ There's no need to use a checkpoint store as persistent subscription checkpoint
 
 ## Producer
 
-In a prototype or small-scale production application, you can use KurrentDB as a message broker. In that case, you can use the `KurrentDBProducer` to publish events to the database. Unlike the aggregate store, [producers](../../../producers) allow publishing events that aren't necessarily domain events.
+In a prototype or small-scale production application, you can use KurrentDB as a message broker. In that case, you can use the `KurrentDBProducer` to publish events to the database. Unlike the aggregate store, [producers](../../producers) allow publishing events that aren't necessarily domain events.
 
 You can then register the `KurrentDBProducer` in the DI container. As the producer needs the `KurrentDBClient` or `KurrentDBClientSettings` as a dependency, you need to register those as well.
 
diff --git a/docs/src/content/docs/next/infra/mongodb.md b/docs/src/content/docs/next/infra/mongodb.md
index c559171e8..5fdd9f5d4 100644
--- a/docs/src/content/docs/next/infra/mongodb.md
+++ b/docs/src/content/docs/next/infra/mongodb.md
@@ -5,13 +5,13 @@ sidebar:
   order: 2
 ---
 
-MongoDB is a popular document database, and Eventuous natively supports projecting events to it. In combination with Mongo [checkpoint store](../../../subscriptions/checkpoint) you can comfortably use MongoDB as a queryable store for your read models.
+MongoDB is a popular document database, and Eventuous natively supports projecting events to it. In combination with Mongo [checkpoint store](../../subscriptions/checkpoint) you can comfortably use MongoDB as a queryable store for your read models.
 
 The base class for a MongoDB projection is `MongoProjection<T>` where `T` is a record derived from the `ProjectedDocument` abstract record.
 
 ## Projected document
 
-The `ProjectedDocument` record has two properties: `Id`, which is used as the document id, and `Position`. The `Position` property is set by the Mongo projection implicitly when an event is projected to a document. The value set for this property is the projection position in the subscribed stream. You can use this information for addressing the [consistency concern](../../../read-models/rm-concept#dealing-with-stale-data).
+The `ProjectedDocument` record has two properties: `Id`, which is used as the document id, and `Position`. The `Position` property is set by the Mongo projection implicitly when an event is projected to a document. The value set for this property is the projection position in the subscribed stream. You can use this information for addressing the [consistency concern](../../read-models/rm-concept#dealing-with-stale-data).
 
 Here is an example of a document model from the sample application:
 
@@ -245,4 +245,4 @@ public class MyBookingsProjection : MongoProjection<MyBookings> {
 
 MongoDB projection is an event handler, so it can be added to a subscription using the `AddEventHandler` extension of the subscription builder.
 
-You can find examples of adding handlers to subscriptions in the [subscription documentation](../../../subscriptions/sub-base#registration).
+You can find examples of adding handlers to subscriptions in the [subscription documentation](../../subscriptions/sub-base#registration).
diff --git a/docs/src/content/docs/next/infra/mssql.md b/docs/src/content/docs/next/infra/mssql.md
index 18809be28..4cb45129e 100644
--- a/docs/src/content/docs/next/infra/mssql.md
+++ b/docs/src/content/docs/next/infra/mssql.md
@@ -5,3 +5,206 @@ sidebar:
   order: 4
 ---
 
+Microsoft SQL Server is a popular choice for storing queryable application data. Many organizations that use .NET as their preferred stack also use SQL Server.
+
+Eventuous supports SQL Server as an event store and also allows subscribing to the global event log and to individual streams using catch-up subscriptions.
+
+## Data model
+
+Eventuous uses a single table to store events. The table name is `Messages`. In addition, another table called `Streams` is used to control the stream existence, and store the last event number for each stream. In the `Messages` table, events and metadata are stored as `NVARCHAR(max)` columns. The table schema is as follows:
+
+```sql
+MessageId      UNIQUEIDENTIFIER      NOT NULL,
+MessageType    NVARCHAR(128)         NOT NULL,
+StreamId       INT                   NOT NULL,
+StreamPosition INT                   NOT NULL,
+GlobalPosition BIGINT IDENTITY (0,1) NOT NULL,
+JsonData       NVARCHAR(max)         NOT NULL,
+JsonMetadata   NVARCHAR(max),
+Created        DATETIME2
+```
+
+For subscriptions, Eventuous adds a table called `Checkpoints` that stores the last processed event number for each subscription. It is then used by the checkpoint store implementation for SQL Server.
+
+## Event persistence
+
+Before using SQL Server as an event store, you need to register the SQL Server-based event store implementation.
+For that to work, you'd also need to register an SQL Server connection detail used to create connections to the database.
+Eventuous provides a few overloads for `AddEventuousSqlServer` registration extension to do that.
+
+One way to register the connection details is to provide a connection string and, optionally, the schema name:
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousSqlServer(connectionString, "mySchema", true);
+```
+
+If the schema name is not provided, the default schema name (`eventuous`) will be used.
+
+Another way to register the connection details is by using configuration options. For example, you can add the following to the settings file:
+
+```json title="appSettings.json"
+{
+  "SqlServerStore": {
+    "Schema": "mySchema",
+    "ConnectionString": "Server=127.0.0.1,57456;Database=master;User Id=sa;Password=password;TrustServerCertificate=True",
+    "InitializeDatabase": true
+  }
+}
+```
+
+Then, use the configuration section to register the connection details:
+
+```csharp title="Program.cs"
+builder.Services.AddEventuousSqlServer(
+    builder.Configuration.GetSection("SqlServerStore")
+);
+```
+
+The `InitializeDatabase` setting tells Eventuous if it needs to create the schema. If you create the schema in a separate migration application, set this setting to `false`. If the schema cannot be found, and the `InitializeDatabase` setting is set to `false`, the application will fail to start.
+
+Next, you need to register the SQL Server event store:
+
+```csharp
+builder.Services.AddEventStore<SqlServerStore>();
+```
+
+When that's done, Eventuous will use SQL Server for persistence in command services.
+
+:::note
+At this moment, the SQL Server event store implementation doesn't support stream truncation.
+:::
+
+## Subscriptions
+
+Eventuous supports two types of subscriptions to SQL Server: global and stream. The global subscription is a catch-up subscription, which means that it reads all events from the beginning of the event log. The stream subscription is also a catch-up subscription, but it only reads events from a specific stream.
+
+Both subscription types use continuous polling to check for new events.
+
+### Registering subscriptions
+
+Registering a global log subscription is similar to [KurrentDB](../esdb#all-stream-subscription). The only difference is the subscription and the options types:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqlServerAllStreamSubscription, SqlServerAllStreamSubscriptionOptions>(
+    "BookingsProjections",
+    b => b
+        .AddEventHandler<BookingStateProjection>()
+        .AddEventHandler<MyBookingsProjection>()
+);
+```
+
+When you register a subscription to a single stream, you need to configure the subscription options to specify the stream name:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqlServerStreamSubscription, SqlServerStreamSubscriptionOptions>(
+    "StreamSubscription",
+    b => b
+        .Configure(x => x.StreamName = "my-stream")
+        .AddEventHandler<StreamSubscriptionHandler>()
+);
+```
+
+As subscriptions use the SQL Server connection details for opening the connection, there's no need to register additional dependencies apart from calling `AddEventuousSqlServer` as described in [event persistence](#event-persistence) section above.
+
+### Checkpoint store
+
+Catch-up subscriptions need a [checkpoint](../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, and it will be used for all subscriptions in the application.
+
+Remember to store the checkpoint in the same database as the read model.
+For example, if you use Postgres as an event store, and project events to read models in MongoDB, you need to use the `MongoCheckpointStore`.
+Eventuous also has a checkpoint store implementation for SQL Server (`SqlServerCheckpointStore`), which you can use if you project events to SQL Server.
+
+When using the SQL Server checkpoint store, you can register it using a dedicated extension function:
+
+```csharp
+builder.Services.AddSqlServerCheckpointStore();
+```
+
+This registration function will use the schema name provided when you register the connection details using `AddEventuousSqlServer`.
+If checkpoints need to be stored in another SQL Server instance, database, or schema, you'd need to register an instance of `SqlServerCheckpointStoreOptions` to configure that:
+
+```csharp
+builder.Services.AddSingleton(
+    new SqlServerCheckpointStoreOptions(anotherConnectionString, anotherSchema)
+);
+builder.Services.AddSqlServerCheckpointStore();
+```
+
+When you also plan to use a different SQL Server database (not the one where events are stored) for both checkpoints and read models,
+you can override the `SqlServerConnectionOptions` that are used by both checkpoint store and projectors (see below). It _must_ be done before calling `AddEventuousSqlServer`.
+
+```csharp
+builder.Services.AddSingleton(
+    new SqlServerCheckpointStoreOptions(anotherConnectionString, anotherSchema)
+);
+builder.Services.AddSqlServerCheckpointStore();
+builder.Services.AddEventuousSqlServer(
+    builder.Configuration.GetSection("SqlServerStore")
+);
+```
+
+Connection details from `SqlServerConnectionOptions` are used by default by the checkpoint store and projectors.
+
+### Projections
+
+You can use SQL Server both as an event store and as a read model store. In that case, you can use the same connection factory for both the event store, the checkpoint store, and the projector.
+
+Eventuous provides a simple projector base class, which allows you to emit SQL statements for the events you want to project, and the projector will execute them.
+
+Consider the following table schema for the query model:
+
+```sql
+IF OBJECT_ID('__schema__.Bookings', 'U') IS NULL
+BEGIN
+  CREATE TABLE __schema__.Bookings (
+    BookingId VARCHAR(1000) NOT NULL PRIMARY KEY,
+    CheckinDate DATETIME2,
+    Price NUMERIC(10,2)
+  );
+END
+```
+
+You can project the `BookingImported` event to this table using a simple projector:
+
+```csharp title="ImportingBookingsProjector.cs"
+public class ImportingBookingsProjector : SqlServerProjector {
+    public ImportingBookingsProjector(SqlServerConnectionOptions options) : base(options) {
+        var insert = $"""
+                      INSERT INTO {options.Schema}.Bookings
+                      (BookingId, CheckinDate, Price)
+                      VALUES (@BookingId, @CheckinDate, @Price)
+                      """;
+
+        On<BookingEvents.BookingImported>(
+            (connection, ctx) =>
+                Project(
+                    connection,
+                    insert,
+                    new SqlParameter("@BookingId", ctx.Stream.GetId()),
+                    new SqlParameter("@CheckinDate", ctx.Message.CheckIn.ToDateTimeUnspecified()),
+                    new SqlParameter("@Price", ctx.Message.Price)
+                )
+        );
+    }
+}
+```
+
+There, `Project` is a small helper function that creates a command from a given connection, sets the command type to `Text`, assigns the given SQL statement, and adds parameters to the command. It then returns the command, so it can be executed by the projector.
+
+You can then register the projector as a subscription handler:
+
+```csharp title="Program.cs"
+builder.Services.AddSubscription<SqlServerAllStreamSubscription, SqlServerAllStreamSubscriptionOptions>(
+    "ImportedBookingsProjections",
+    b => b
+        .UseCheckpointStore<SqlServerCheckpointStore>()
+        .AddEventHandler<ImportingBookingsProjector>()
+);
+```
+
+:::note
+You only need to explicitly specify the subscription checkpoint store with `UseCheckpointStore` if your application uses different checkpoint stores for different subscriptions.
+At this moment, there is no way to use different checkpoint store options for each subscription in the same application, they will all use the same `SqlServerCheckpointStoreOptions` or `SqlServerConnectionOptions`.
+:::
+
+Note that the `insert` operation in the projection is not idempotent, so if the event is processed twice because there was a failure, the projector will throw an exception. It would not be an issue when the subscription uses the default setting that tells it not to stop when the handler fails. If you want to ensure that failures force the subscription to throw, you can change the subscription option `ThrowOnError` to `true`, and make the operation idempotent by using "insert or update".
diff --git a/docs/src/content/docs/next/infra/postgres.md b/docs/src/content/docs/next/infra/postgres.md
index a86fe5d4a..c1ea9ce89 100644
--- a/docs/src/content/docs/next/infra/postgres.md
+++ b/docs/src/content/docs/next/infra/postgres.md
@@ -65,7 +65,7 @@ builder.Services.Configure<PostgresStoreOptions>(
 );
 ```
 
-When that's done, Eventuous would persist aggregates in Postgres when you use the [command service](../../../application/app-service).
+When that's done, Eventuous would persist aggregates in Postgres when you use the [command service](../../application/app-service).
 
 At this moment, the Postgres event store implementation doesn't support stream truncation.
 
@@ -101,7 +101,7 @@ builder.Services.AddSubscription<PostgresStreamSubscription, PostgresStreamSubsc
 
 ### Checkpoint store
 
-Catch-up subscriptions need a [checkpoint](../../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, and it will be used for all subscriptions in the application.
+Catch-up subscriptions need a [checkpoint](../../subscriptions/checkpoint). You can register the checkpoint store using `AddCheckpointStore<T>`, and it will be used for all subscriptions in the application.
 
 Remember to store the checkpoint in the same database as the read model. For example, if you use Postgres as an event store, and project events to read models in MongoDB, you need to use the `MongoCheckpointStore`. Eventuous also has a checkpoint store implementation for Postgres (`PostgresCheckpointStore`), which you can use if you project events to Postgres.
 
diff --git a/docs/src/content/docs/next/infra/rabbitmq.md b/docs/src/content/docs/next/infra/rabbitmq.md
index 2cdc3da26..bf5bd372a 100644
--- a/docs/src/content/docs/next/infra/rabbitmq.md
+++ b/docs/src/content/docs/next/infra/rabbitmq.md
@@ -5,4 +5,155 @@ sidebar:
   order: 5
 ---
 
-WIP
\ No newline at end of file
+## Introduction
+
+RabbitMQ is a popular message broker, and it can serve as a great integration infrastructure for communicating
+between services. Eventuous supports using RabbitMQ messaging with [producers](../../producers) for producing messages
+and [subscriptions](../../subscriptions/subs-concept) for consuming messages.
+
+Eventuous producer for RabbitMQ publishes messages to _exchanges_.
+An exchange can be considered similar to topics in other message brokers like Kafka or Google Pub/Sub, but, unlike topics, those messages are not persistent.
+Messages published to an exchange are distributed to queues that _bound_ (subscribed) to the exchange.
+When an exchange doesn't have any bindings, all the messages published to that exchange disappear.
+
+To make RabbitMQ messaging work, you need to have exchanges and queues that bind to those exchanges. Eventuous creates an exchange by default if it doesn't exist when producing and consuming messages.
+
+When using RabbitMQ for integration between services, the usual pattern is to have one exchange per service. Alternatively, one exchange can be used for messages about one logical topic like aggregate type or stream category.
+
+## Producer
+
+Eventuous RabbitMQ producer works the same way as any other message producer. It allows you to publish messages to RabbitMQ exchanges. Those messages can then be consumed by services that use Eventuous RabbitMQ subscriptions. You can also use other messaging libraries to consume messages as Eventuous doesn't manipulate sent messages in any way.
+
+### Configuration
+
+RabbitMQ producer's constructor requires the connection factory argument. When using the default ASP.NET Core dependency injection, you'd register the connection factory instance in the DI container as part of the bootstrap code. At the bare minimum, you need a RabbitMQ connection string to create a connection factory instance:
+
+```csharp
+builder.Services.AddSingleton(
+    new ConnectionFactory {
+        Uri = new Uri(rabbitMqConnectionString)
+    }
+);
+```
+
+When that's done, you can register the producer by using `AddProducer` extension provided by Eventuous:
+
+```csharp
+builder.Services.AddProducer<RabbitMqProducer>();
+```
+
+As the producer will create an exchange when it publishes a message, but the exchange doesn't exist, you can inform the producer how to configure those new exchanges. To do it, you can register or supply an instance of `RabbitMqExchangeOptions`. Available options are:
+
+| Option       | Description                                         | Default value |
+|--------------|-----------------------------------------------------|---------------|
+| `Type`       | Exchange type                                       | `Fanout`      |
+| `Durable`    | If the messages should be stored on disk            | `true`        |
+| `AutoDelete` | If the exchange should disappear when it's not used | `false`       |
+
+We recommend using the default exchange options, unless you want to use [routing keys][3] because fan-out exchanges don't support routing. Use exchange type `Direct` or `Topic` if you need to use RabbitMQ routing features.
+
+### Producing messages
+
+The producer publishes messages to a RabbitMQ exchange where the exchange name is the `streamName` parameter value.
+
+When you tell the producer to publish a message to an exchange, it will check if the exchange exists. If the exchange doesn't exist, the producer will create one using the exchange options described above. This check only happens once per service lifetime, so it doesn't affect performance.
+
+As the RabbitMQ producer implements the same `IProducer` interface as any other Eventuous producer, it has the same API as described on the [Producers](../../producers/implementation) page.
+
+It's possible to tune the producer's behaviour when producing messages by supplying an optional produce option. For RabbitMQ, those options are represented by the `RabbitMqProduceOptions` record with the following properties:
+
+| Option           | Description                                                                      |
+|------------------|----------------------------------------------------------------------------------|
+| `AppId`          | Application name                                                                 |
+| `Expiration`     | Time-to-live for the message in milliseconds ([read more][2])                    |
+| `Persisted`      | If the message should be persisted on disk, default is `true`                    |
+| `Priority`       | Message priority, from 0 to 9                                                    |
+| `RoutingKey`     | [Routing key][3] of the message, doesn't work with fan-out exchanges             |
+
+When the produced message has metadata, all metadata values will be converted to message headers. Subscriptions will restore headers back to metadata. If message metadata contains a correlation id (`eventuous.correlation-id` key), the value will be added to the RabbitMQ message correlation id property.
+
+## Subscriptions
+
+Eventuous supports consuming messages from RabbitMQ using [subscriptions](../../subscriptions/subs-concept).
+
+### Configuration
+
+As any other subscription, it can be added to the DI container using `AddSubscription` extension:
+
+```csharp
+builder.Services.AddSubscription<RabbitMqSubscription, RabbitMqSubscriptionOptions>(
+    "PaymentsIntegration",
+    b => b
+        .Configure(cfg => cfg.Exchange = "payments")
+        .AddEventHandler<PaymentsHandler>()
+);
+```
+
+The `Exchange` configuration property is mandatory as the subscription needs to know where it should consume messages from. Also, the subscription has a mandatory dependency on `ConnectionFactory`, so you'd need to register it in the container as described in the [producer configuration](#configuration) section above.
+
+For consuming messages, the subscription needs a queue bound to the specified exchange. By default, the subscription id is used as the queue name. You can override the queue name by specifying an alternative value using `QueueOptions.Queue` property of the subscription options.
+
+Besides the queue name, it's possible to configure the subscription with RabbitMQ-specific parameters. Those include queue options, exchange options, and binding options. Eventuous provides default values for all those, so usually you would not need to change those. One option that likely should be overridden is the concurrency limit value, which is set to `1` by default. As RabbitMQ doesn't guarantee message ordering anyway, you can speed up message processing by increasing the concurrency limit, so the subscription can consume messages in parallel. Eventuous will also adjust the prefetch count to accommodate for increased number of consumers, if necessary.
+
+As mentioned previously, RabbitMQ messages are published to an exchange and consumed from a queue bound to that exchange. When the subscription starts, it makes sure that both the exchange and the queue exist, and the queue is bound to the exchange. If you start producing messages to an exchange created by the producer before starting the subscription at least once, and there's no queue and binding created upfront, those messages will be dropped. As long as the exchange has a binding to a subscription queue, the messages will be kept in the queue until consumed. Therefore, we recommend starting the subscription before producing messages.
+
+RabbitMQ subscriptions can be configured using the following options:
+
+| Option             | Description                                                                                        |
+|--------------------|----------------------------------------------------------------------------------------------------|
+| `Exchange`         | Exchange name that the subscription binds to                                                       |
+| `FailureHandler`   | Function to handle message processing errors, described [below](#error-handling)                   |
+| `ExchangeOptions`  | Exchange options (see Producer configuration above)                                                |
+| `QueueOptions`     | Subscription queue options (see below)                                                             |
+| `BindingOptions`   | Options for the binding between the exchange and the queue (see below)                             |
+| `ConcurrencyLimit` | The number of parallel consumers, default is one                                                   |
+| `PrefetchCount`    | The number of [in-flight messages][1] per consumer, default is concurrency limit multiplied by two |
+
+:::note[Exchange configuration]
+Please remember that both the producer and the subscription can create the exchange, depending on which initiates first.
+In case the exchange options set by the producer and the subscription are different, the exchange will not undergo any updates.
+It is important to note that exchange options are only taken into account at the time of exchange creation.
+:::
+
+:::note[Queue and binding configuration]
+Both the queue and the binding are only applied when those elements are created.
+Any changes to the queue and bindings that happen afterward won't trigger updating queues and bindings.
+You can still update those using RabbitMQ management API.
+:::
+
+For configuring the subscription queue, the following options are available in `RabbitMqQueueOptions`:
+
+| Name         | Description                                                                       |
+|--------------|-----------------------------------------------------------------------------------|
+| `Queue`      | Overrides the default queue name, which is set to subscription id by default      |
+| `AutoDelete` | Default is `false`, so the queue will survive restarts                            |
+| `Exclusive`  | Default is `false`, change it if you want to only have a single consumer instance |
+| `Durable`    | Default is `true`, so the queue will be persisted on disk                         |
+
+Finally, you can configure exchange-to-queue binding using `RabbitMqBindingOptions`:
+
+| Name         | Description                                                                       |
+|--------------|-----------------------------------------------------------------------------------|
+| `RoutingKey` | Optional [routing key][3] for the binding, it doesn't work with fan-out exchanges |
+
+If you set the routing key for the binding but the exchange is configured as fan-out, Eventuous will produce a warning but will create the binding. Routing key specified when producing messages will be ignored for fan-out exchanges.
+
+### Error handling
+
+Eventuous subscriptions don't throw exceptions when the message handler fails. This behaviour can be changed by changing the `ThrowOnError` subscription option. For RabbitMQ subscriptions, this behaviour is extended by using the requeue feature of the broker. Therefore, by default, if the message handler throws an exception, the message will be put back in the queue and consumed again later. This helps to deal with transient failures in the message handler but also severely impacts message processing order as the retried message is put at the end of the queue.
+
+If you want to ensure that messages are consumed in relative order, you'd need to make sure that message processing is retried inside the handler. Still, if the error doesn't get resolved by retries, the consumer will eventually time out and the message will be put back in the queue. If the message is causing the consumer to fail unconditionally, it is a _poison message_, and it can take put the system into an endless retry loop.
+
+The requeue behaviour is provided by the default failure handler. It's possible to override it by setting the `FailureHandler` property of the subscription options.
+
+## Other messaging frameworks
+
+It's important to understand how Eventuous messaging for RabbitMQ is different compared to other messaging middleware libraries for .NET like MassTransit or NServiceBus.
+
+The most noticeable difference is that both MassTransit and NServiceBus use _message-type-based routing_. It means that by default, they create exchanges for each message type produced by the application. Another default is that the .NET class name is used to compute the exchange name. As a result, any refactoring of the message schema code, like renaming classes, changing namespaces, etc., causes disruption for downstream consumers. As fully qualified class names are also used for deserialization, changes in message class names as well as their namespaces causes issue for downstream consumers and requires coordinated deployments.
+
+Eventuous uses a different approach where the service normally produces messages to its own single exchange which is named after the service. Each subscription gets its own queue and creates a binding to a particular exchange. So, each consumer will get messages with different types, from a particular service. Message type is supplied as a default RabbitMQ `Type` message property. It uses Eventuous [type map](../../persistence/serialisation#type-map) for mapping CLR types to strings, so refactoring namespaces and class name will not affect message routing. In addition, messages are delivered in relative order from one service to another. Certainly, it might affect the system performance as if the subscription queue gets congested, it will keep growing. That can be mitigated by using message priority, which is supported by RabbitMQ.
+
+[1]: https://www.rabbitmq.com/docs/confirms#channel-qos-prefetch
+[2]: https://www.rabbitmq.com/docs/ttl#per-message-ttl-in-publishers
+[3]: https://www.rabbitmq.com/tutorials/tutorial-four-dotnet
diff --git a/docs/src/content/docs/next/infra/sqlite.md b/docs/src/content/docs/next/infra/sqlite.md
index 935d11ed7..d7a7c34ac 100644
--- a/docs/src/content/docs/next/infra/sqlite.md
+++ b/docs/src/content/docs/next/infra/sqlite.md
@@ -62,7 +62,7 @@ builder.Services.AddEventuousSqlite(
 builder.Services.AddEventStore<SqliteStore>();
 ```
 
-When that's done, Eventuous will persist aggregates in SQLite when you use the [command service](../../../application/app-service).
+When that's done, Eventuous will persist aggregates in SQLite when you use the [command service](../../application/app-service).
 
 ## Subscriptions
 
@@ -96,7 +96,7 @@ builder.Services.AddSubscription<SqliteStreamSubscription, SqliteStreamSubscript
 
 ### Checkpoint store
 
-Catch-up subscriptions need a [checkpoint](../../../subscriptions/checkpoint). You can register the SQLite checkpoint store, and it will be used for all subscriptions in the application:
+Catch-up subscriptions need a [checkpoint](../../subscriptions/checkpoint). You can register the SQLite checkpoint store, and it will be used for all subscriptions in the application:
 
 ```csharp title="Program.cs"
 builder.Services.AddSqliteCheckpointStore();
diff --git a/docs/src/content/docs/next/persistence/aggregate-store.mdx b/docs/src/content/docs/next/persistence/aggregate-store.mdx
index ded37c17f..706c9712d 100644
--- a/docs/src/content/docs/next/persistence/aggregate-store.mdx
+++ b/docs/src/content/docs/next/persistence/aggregate-store.mdx
@@ -2,10 +2,14 @@
 title: "Aggregate store"
 description: "How aggregates are stored in an event store"
 ---
-import ThemedImage from '../../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import replication from './images/replication.png';
+import replicationDark from './images/replication-dark.png';
+import reading from './images/reading.png';
+import readingDark from './images/reading-dark.png';
 
 :::info
-Eventuous does not have a concept of Repository. Find out why [on this page](../../../persistence).
+Eventuous does not have a concept of Repository. Find out why [on this page](../../persistence).
 :::
 
 Eventuous provides a single abstraction for the domain objects persistence, which is the `AggregateStore`.
@@ -20,7 +24,7 @@ The `AggregateStore` constructor needs two arguments:
 - [Event store](../event-store) (`IEventStore`)
 - [Event serializer](../serialisation) (`IEventSerializer`)
 
-Our [`CommandService`](../../../application/app-service) uses the `IEventStore` in its command-handling flow.
+Our [`CommandService`](../../application/app-service) uses the `IEventStore` in its command-handling flow.
 
 ## Using KurrentDB
 
@@ -59,8 +63,8 @@ The connector is running continuously, and it copies all the events from the hot
 
 <ThemedImage
     alt="Replication process"
-    lightSrc="./images/replication.png"
-    darkSrc="./images/replication-dark.png"
+    lightSrc={replication}
+    darkSrc={replicationDark}
 />
 
 As the connector replicates all the events, there's no need to perform an explicit archive action when storing the events normally using the regular event store.
@@ -102,8 +106,8 @@ From there, the process of loading an aggregate is seamless from the outside, bu
 
 <ThemedImage
     alt="Reading from two stores"
-    lightSrc="./images/reading.png"
-    darkSrc="./images/reading-dark.png"
+    lightSrc={reading}
+    darkSrc={readingDark}
 />
 
 Here's the reading process described step-by-step:
diff --git a/docs/src/content/docs/next/prologue/the-right-way.mdx b/docs/src/content/docs/next/prologue/the-right-way.mdx
index 8fd805cf9..2cdb295a1 100644
--- a/docs/src/content/docs/next/prologue/the-right-way.mdx
+++ b/docs/src/content/docs/next/prologue/the-right-way.mdx
@@ -4,7 +4,9 @@ description: >
     Event Sourcing done right, as it meant to be. Don't get caught up in the misconception that Event Sourcing is the same thing
     as Event-Driven Architecture.
 ---
-import ThemedImage from '../../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import theRightWay from './images/the-right-way.png';
+import theRightWayDark from './images/the-right-way-dark.png';
 
 If you've ever searched for a diagram that explains Event Sourcing, you may have found many images, but most of them are confusing or simply incorrect. Despite claims that Event Sourcing is difficult, many people who have this opinion have never actually tried it or made mistakes during implementation.
 
@@ -26,8 +28,8 @@ Please refer to the diagram below for a complete understanding of the process.
 
 <ThemedImage
     alt="Eventuous way"
-    lightSrc="./images/the-right-way.png"
-    darkSrc="./images/the-right-way-dark.png"
+    lightSrc={theRightWay}
+    darkSrc={theRightWayDark}
 />
 
 ## What's wrong with those other diagrams?
diff --git a/docs/src/content/docs/next/subscriptions/checkpoint.mdx b/docs/src/content/docs/next/subscriptions/checkpoint.mdx
index bba2cbbb0..d0e689c86 100644
--- a/docs/src/content/docs/next/subscriptions/checkpoint.mdx
+++ b/docs/src/content/docs/next/subscriptions/checkpoint.mdx
@@ -2,7 +2,9 @@
 title: "Checkpoints"
 description: "What's a checkpoint and why you need to store it"
 ---
-import ThemedImage from '../../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import commitHandler from './images/commit-handler.png';
+import commitHandlerDark from './images/commit-handler-dark.png';
 
 When subscribing to an event store, it is important to consider which events you wish to receive. An effective event store should allow you to subscribe to individual event streams or to a global stream known as the "All stream", which contains all events in the store, organized in the order they were recorded. Many event-driven brokers that persist events as ordered logs also support subscriptions, which are often referred to as "consumers".
 
@@ -106,6 +108,28 @@ In addition to that, Eventuous has two implementations in the core subscriptions
 
 The measured store is used by default if Eventuous diagnostics aren't disabled, and you use the `AddCheckpointStore` container registration extension.
 
+## Initial position
+
+When a subscription starts for the first time and no checkpoint exists, it needs to decide where to begin reading events. By default, subscriptions start from the **earliest** position (the beginning of the stream). You can change this behaviour using the `StartFrom` option on any subscription that uses checkpoints:
+
+```csharp
+builder.Services.AddSubscription<MySubscription, MySubscriptionOptions>(
+    "MySubscription",
+    b => b
+        .Configure(cfg => cfg.StartFrom = InitialPosition.Latest)
+        .AddEventHandler<MyHandler>()
+);
+```
+
+| Value | Description |
+|---|---|
+| `InitialPosition.Earliest` | Start from the beginning of the stream (default). Processes all historical events. |
+| `InitialPosition.Latest` | Start from the current end of the stream. Only processes events produced after the subscription starts. |
+
+:::note
+The `StartFrom` option only applies when there is no existing checkpoint. Once a checkpoint is stored, the subscription always resumes from the last committed checkpoint position, regardless of the `StartFrom` setting.
+:::
+
 ## Checkpoint commit handler
 
 In addition to checkpoint store, Eventuous has a more advanced way to work with checkpoints. It doesn't load or store checkpoints by itself, for that purpose it uses the provided checkpoint store. However, the commit handler is able to receive a stream of unordered checkpoints, reorder them, detect possible gaps, and only store the checkpoint that is the latest before the gap.
@@ -118,8 +142,8 @@ When events get partitioned by the filter, several consumer instances process ev
 
 <ThemedImage
     alt="Gap in the commit handler queue"
-    lightSrc="./images/commit-handler.png"
-    darkSrc="./images/commit-handler-dark.png"
+    lightSrc={commitHandler}
+    darkSrc={commitHandlerDark}
 />
 
 :::note
diff --git a/docs/src/content/docs/next/subscriptions/eventhandler.md b/docs/src/content/docs/next/subscriptions/eventhandler.md
index 6e23612a6..339f5243c 100644
--- a/docs/src/content/docs/next/subscriptions/eventhandler.md
+++ b/docs/src/content/docs/next/subscriptions/eventhandler.md
@@ -39,7 +39,7 @@ The outcome of events that were not acknowledged by the consumer depends on the
 
 If you need to implement a custom handler, such as a projector to a relational database, you typically use the `EventHandler` abstraction provided by Eventuous. This abstraction allows you to register typed handlers for specific event types in a map, and the HandleEvent function is already implemented in the interface, which will call the registered handler or return Ignored if no handler is registered for a given event type.
 
-The `EventHandler` base class takes a [`TypeMapper`](../../../persistence/serialisation#type-map) instance as a constructor argument. If a constructor argument is not provided, the default type mapper instance will be used. The `On<TEvent>` function uses the type mapper to check if the event type `TEvent` is registered in the type map, thus proactively causing the program to crash during startup if a handler is defined for an unregistered event type.
+The `EventHandler` base class takes a [`TypeMapper`](../../persistence/serialisation#type-map) instance as a constructor argument. If a constructor argument is not provided, the default type mapper instance will be used. The `On<TEvent>` function uses the type mapper to check if the event type `TEvent` is registered in the type map, thus proactively causing the program to crash during startup if a handler is defined for an unregistered event type.
 
 As an example, consider a simple handler that prints *$$$ MONEY! You got USD 100!* to the console when it receives the `PaymentRegistered` event, where the event's paid amount property is 100 and its currency is USD.
 
diff --git a/docs/src/content/docs/next/subscriptions/pipes.mdx b/docs/src/content/docs/next/subscriptions/pipes.mdx
index 712ed0b8c..891cd03a0 100644
--- a/docs/src/content/docs/next/subscriptions/pipes.mdx
+++ b/docs/src/content/docs/next/subscriptions/pipes.mdx
@@ -2,7 +2,13 @@
 title: "Consume pipe"
 description: "Subscription consume pipes and filters"
 ---
-import ThemedImage from '../../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import defaultPipe from './images/default-pipe.png';
+import defaultPipeDark from './images/default-pipe-dark.png';
+import concurrentFilter from './images/concurrent-filter.png';
+import concurrentFilterDark from './images/concurrent-filter-dark.png';
+import partitioningFilter from './images/partitioning-filter.png';
+import partitioningFilterDark from './images/partitioning-filter-dark.png';
 
 ## Pipes and filters
 
@@ -12,8 +18,8 @@ Eventuous consume pipe can be customised by adding filters to it, but normally y
 
 <ThemedImage
     alt="Default consume pipeline"
-    lightSrc="./images/default-pipe.png"
-    darkSrc="./images/default-pipe-dark.png"
+    lightSrc={defaultPipe}
+    darkSrc={defaultPipeDark}
 />
 
 Some subscriptions conditionally or unconditionally add filters to the pipe, when they detect the default pipe. For example, KurrentDB catch-up subscription might add the concurrent filter and partitioning filter, and RabbitMQ subscription uses the concurrent filter.
@@ -56,7 +62,7 @@ Such a subscription will ignore all the events that have the type starting with
 
 ### Tracing filter
 
-The tracing filter gets added automatically when Eventuous diagnostics is enabled (or, not disabled, as it's enabled by default). Read more about Eventuous tracing in the [Diagnostics](../../../diagnostics) section.
+The tracing filter gets added automatically when Eventuous diagnostics is enabled (or, not disabled, as it's enabled by default). Read more about Eventuous tracing in the [Diagnostics](../../diagnostics) section.
 
 ### Concurrent filter
 
@@ -66,8 +72,8 @@ Because of such a split, the result returned to the subscription doesn't contain
 
 <ThemedImage
     alt="Pipe with concurrent filter"
-    lightSrc="./images/concurrent-filter.png"
-    darkSrc="./images/concurrent-filter-dark.png"
+    lightSrc={concurrentFilter}
+    darkSrc={concurrentFilterDark}
 />
 
 The concurrent filter is useful in combination with partitioning filter, but it can also be used for other purposes, like batched event processing.
@@ -84,8 +90,8 @@ Sometimes the subscription workload gets too high for it to cope with the number
 
 <ThemedImage
     alt="Pipe with concurrent and partitioning filters"
-    lightSrc="./images/partitioning-filter.png"
-    darkSrc="./images/partitioning-filter-dark.png"
+    lightSrc={partitioningFilter}
+    darkSrc={partitioningFilterDark}
 />
 
 You can use two options for configuring the filter:
diff --git a/docs/src/content/docs/next/subscriptions/sub-base.md b/docs/src/content/docs/next/subscriptions/sub-base.md
index 652f9b746..e856af6ac 100644
--- a/docs/src/content/docs/next/subscriptions/sub-base.md
+++ b/docs/src/content/docs/next/subscriptions/sub-base.md
@@ -54,7 +54,7 @@ public ValueTask<EventHandlingStatus> HandleEvent(IMessageConsumeContext ctx) {
 }
 ```
 
-However, it's easier and more explicit to use pre-optimised base handlers. For read model projections you can use [Projections] handlers, described separately. For integration purposes you might want to use the [Gateway](../../../gateway). For more generic needs, Eventuous offers the `EventHandler` base class. It allows specifying typed handlers for each of the event types that the handler processes:
+However, it's easier and more explicit to use pre-optimised base handlers. For read model projections you can use [Projections] handlers, described separately. For integration purposes you might want to use the [Gateway](../../gateway). For more generic needs, Eventuous offers the `EventHandler` base class. It allows specifying typed handlers for each of the event types that the handler processes:
 
 ```csharp
 public class MyHandler : EventHandler {
@@ -80,7 +80,7 @@ The subscription will acknowledge the event only if all of its handlers _don't f
 
 ## Registration
 
-As mentioned before, you'd normally register subscriptions using the DI extensions provided by Eventuous. This example uses the [KurrentDB](../../../infra/esdb) subscription.
+As mentioned before, you'd normally register subscriptions using the DI extensions provided by Eventuous. This example uses the [KurrentDB](../../infra/esdb) subscription.
 
 ```csharp title="Program.cs"
 builder.Services.AddSubscription<StreamSubscription, StreamSubscriptionOptions>(
diff --git a/docs/src/content/docs/next/subscriptions/subs-concept.mdx b/docs/src/content/docs/next/subscriptions/subs-concept.mdx
index 36113b3e8..e014f6506 100644
--- a/docs/src/content/docs/next/subscriptions/subs-concept.mdx
+++ b/docs/src/content/docs/next/subscriptions/subs-concept.mdx
@@ -4,7 +4,9 @@ description: "The concept of real-time subscriptions"
 sidebar:
   order: 1
 ---
-import ThemedImage from '../../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import subscriptions from './images/subscriptions.png';
+import subscriptionsDark from './images/subscriptions-dark.png';
 
 Real-time subscriptions are essential when building a successful event-sourced system. They support the following sequence of operations:
 
@@ -31,16 +33,16 @@ By combining those two projections in _one subscription_, they could be both beh
 
 Subscriptions need to maintain their own [checkpoints](../checkpoint), so when the service that host a subscription restarts, it will start receiving events from the last known position in the stream.
 
-Most often, you'd want to subscribe to the _global event stream_, so you can build read models, which compose information from different aggregates. Eventuous offers the [All stream subscription](../../../infra/esdb#all-stream-subscription) for this use case. In some cases you'd need to subscribe to a regular stream using the [stream subscription](../../../infra/esdb#single-stream-subscription).
+Most often, you'd want to subscribe to the _global event stream_, so you can build read models, which compose information from different aggregates. Eventuous offers the [All stream subscription](../../infra/esdb#all-stream-subscription) for this use case. In some cases you'd need to subscribe to a regular stream using the [stream subscription](../../infra/esdb#single-stream-subscription).
 
 In Eventuous, subscriptions are specific to event store implementation. In addition, Eventuous has subscriptions to message brokers like Google PubSub and RabbitMQ for integration purposes.
 
 ## The wrong way
 
-One of the common mistakes people make when building an event-sourced application is using an event store which is not capable of handling realtime subscriptions. It forces developers to engage some sort of message bus to deliver new events to subscribers. There are [quite a few issues](../../../prologue/the-right-way) with that approach, but the most obvious one is a two-phase commit.
+One of the common mistakes people make when building an event-sourced application is using an event store which is not capable of handling realtime subscriptions. It forces developers to engage some sort of message bus to deliver new events to subscribers. There are [quite a few issues](../../prologue/the-right-way) with that approach, but the most obvious one is a two-phase commit.
 
 :::tip[Bad bus]
-Read more about the **[Bad Bus →](../../../prologue/the-right-way#event-bus)**
+Read more about the **[Bad Bus →](../../prologue/the-right-way#event-bus)**
 :::
 
 When using two distinct pieces of infrastructure in one transaction, you risk one of those operations to fail. Let's use the following example code, which is very common:
@@ -62,15 +64,15 @@ It is not hard to avoid the two-phase commits and ensure to publish domain event
 
 <ThemedImage
     alt="Consistent event flow"
-    lightSrc="./images/subscriptions.png"
-    darkSrc="./images/subscriptions-dark.png"
+    lightSrc={subscriptions}
+    darkSrc={subscriptionsDark}
 />
 
 Why is this flow "consistent"? It's because the command handling process always finishes with an append operation towards event store (unless the command fails). There's no explicit `Publish` or `Produce` call that happens after the event is persisted. A proper event store should have a capability for to subscribe for getting all the new events when they appear in the store. As the `Append` operation of the event store is transactional, such a subscription will get the event only once, if it is capable to acknowledge the event correctly back to the subscription.
 
-Subscriptions have many purposes. Most often, you would use a subscription to project domain events to your query models ([read models](../../read-models/rm-concept)). You can also use subscriptions to transform and publish integration events (see [Gateway](../../../gateway)).
+Subscriptions have many purposes. Most often, you would use a subscription to project domain events to your query models ([read models](../../read-models/rm-concept)). You can also use subscriptions to transform and publish integration events (see [Gateway](../../gateway)).
 
-Subscriptions can also be used for integration purposes in combination with [Producers](../../../producers).
+Subscriptions can also be used for integration purposes in combination with [Producers](../../producers).
 
 ## Implementation
 
diff --git a/docs/src/content/docs/next/subscriptions/subs-diagnostics.md b/docs/src/content/docs/next/subscriptions/subs-diagnostics.md
index c7ef67f89..2f346b596 100644
--- a/docs/src/content/docs/next/subscriptions/subs-diagnostics.md
+++ b/docs/src/content/docs/next/subscriptions/subs-diagnostics.md
@@ -5,7 +5,7 @@ description: "Monitoring subscriptions"
 
 Out of the box, Eventuous provides metrics and traces for monitoring your subscriptions.
 
-Also, study the [Diagnostics](../../../diagnostics) section for more information.
+Also, study the [Diagnostics](../../diagnostics) section for more information.
 
 ## Mind the gap
 
diff --git a/docs/src/content/docs/next/whats-new.mdx b/docs/src/content/docs/next/whats-new.mdx
index 88404165d..40fb7263e 100644
--- a/docs/src/content/docs/next/whats-new.mdx
+++ b/docs/src/content/docs/next/whats-new.mdx
@@ -1,7 +1,7 @@
 ---
-title: "What's new"
+title: "What's new (Preview)"
 sidebar:
   order: 1
 ---
 
-# What's new in vNext
+This page will be updated with changes for the next release of Eventuous.
diff --git a/docs/src/content/docs/persistence/aggregate-store.mdx b/docs/src/content/docs/persistence/aggregate-store.mdx
index 25676121c..706c9712d 100644
--- a/docs/src/content/docs/persistence/aggregate-store.mdx
+++ b/docs/src/content/docs/persistence/aggregate-store.mdx
@@ -2,138 +2,133 @@
 title: "Aggregate store"
 description: "How aggregates are stored in an event store"
 ---
+import ThemedImage from '@components/ThemedImage.astro';
+import replication from './images/replication.png';
+import replicationDark from './images/replication-dark.png';
+import reading from './images/reading.png';
+import readingDark from './images/reading-dark.png';
+
+:::info
+Eventuous does not have a concept of Repository. Find out why [on this page](../../persistence).
+:::
 
-:::note[Deprecation notice]
-Since version **0.15**, Eventuous doesn't use _Aggregate store_ internally. All persistence operations in command services are using [Event store](../event-store). The following elements are marked obsolete:
+Eventuous provides a single abstraction for the domain objects persistence, which is the `AggregateStore`.
 
-- `IAggregateStore` interface
-- `AggregateStore` class
-- `AggregateStore<TArchive>` class
-- Dependency injection registration methods for Aggregate store
+The `AggregateStore` uses the `IEventStore` abstraction to be persistence-agnostic, so it can be used as-is, when you give it a proper implementation of event store.
 
-Look in the previous version documentation to learn about `IAggregateStore` and its usage.
-:::
+We have only two operations in the `AggregateStore`:
+- `Load` - retrieves events from an aggregate stream and restores the aggregate state using those events.
+- `Store` - collects new events from an aggregate and stores those events to the aggregate stream.
+
+The `AggregateStore` constructor needs two arguments:
+- [Event store](../event-store) (`IEventStore`)
+- [Event serializer](../serialisation) (`IEventSerializer`)
+
+Our [`CommandService`](../../application/app-service) uses the `IEventStore` in its command-handling flow.
+
+## Using KurrentDB
+
+Eventuous supports [KurrentDB](https://kurrent.io) out of the box, but only v20+ with gRPC protocol.
+
+Using this pre-made event persistence is easy. You can register the necessary dependencies in your startup code:
+
+```csharp title="Program.cs"
+builder.Services.AddKurrentDBClient(connectionString);
+builder.Services.AddEventStore<KurrentDBEventStore>();
+```
 
 :::note
-Eventuous does not have a concept of Repository. Find out why [on this page](..).
+Make sure to read about [events serialisation](../serialisation).
 :::
 
-Eventuous provides a number of extensions for `IEventReader` and `IEventWriter` interfaces for aggregate persistence.
+## Bring your own event store
 
-## Storing aggregates
+You can build your own event store, if you want to use a different database. If you have another implementation of `IEventStore` interface, you can register the aggregate store like this:
 
-Storing an aggregate instance implies appending new events from the list of changes to the [aggregate stream](../aggregate-stream). Functions that allow that are listed below. All those are extensions to `IEventWriter` interface.
+```csharp title="Program.cs"
+builder.Services
+    .AddSingleton<IEventStore>(new MyEventStore(...))
+    .AddAggregateStore<MyEventStore>();
+```
 
-### Using stream name
+## Multi-tier store
 
-This function requires a pre-calculated stream name to be provided, so it doesn't use any convention for resolving stream names. It uses the provided stream name as-is.
+When you have an event-sourced system in production for a while, you might collect a lot of historical events. Some event streams might be as old, as they won't be frequently accessed, but when using a single event store, you'd have to store all those events in a hot store, as it's the only one you have. It might create an issue of misusing the hot store, as those historical events are expensive to keep.
 
-```csharp
-Task<AppendEventsResult> IEventWriter.StoreAggregate<TAggregate, TState>(
-    StreamName        streamName,
-    TAggregate        aggregate,
-    AmendEvent?       amendEvent        = null,
-    CancellationToken cancellationToken = default
-)
-```
+Eventuous has a feature to store historical events in a separate store, called the _Multi-tier store_. It works best when combined with a connector, which copies all the events from the hot store to the archive store real-time. Here, you find an example of using Elasticsearch as the archive store.
 
-| Parameter           | Type                             | Description                                             |
-|---------------------|----------------------------------|---------------------------------------------------------|
-| `streamName`        | `StreamName`                     | Aggregate stream name                                   |
-| `aggregate`         | `TAggregate<TState>`             | Aggregate instance                                      |
-| `amendEvent`        | `Func<StreamEvent, StreamEvent>` | Function that allows adding things like custom metadata |
-| `cancellationToken` | `CancellationToken`              | Cancellation token                                      |
-
-### Using explicit aggregate id
-
-This function uses the stream name map to convert the provided aggregate identity to a stream name. If the stream name map is not supplied, it will use the default, convention-based calculation (`TypeName-Id`).
-
-```csharp
-Task<AppendEventsResult> IEventWriter.StoreAggregate<TAggregate, TState, TId>(
-    TAggregate        aggregate,
-    TId               id,
-    StreamNameMap?    streamNameMap     = null,
-    AmendEvent?       amendEvent        = null,
-    CancellationToken cancellationToken = default
-)
-```
+### Archive in real-time
 
-| Parameter           | Type                             | Description                                                                        |
-|---------------------|----------------------------------|------------------------------------------------------------------------------------|
-| `aggregate`         | `TAggregate<TState>`             | Aggregate instance                                                                 |
-| `id`                | `TId`                            | Aggregate identity                                                                 |
-| `streamNameMap`     | `StreamNameMap`                  | [Map](../aggregate-stream#aggregate-streams) between identities and stream names |
-| `amendEvent`        | `Func<StreamEvent, StreamEvent>` | Function that allows adding things like custom metadata                            |
-| `cancellationToken` | `CancellationToken`              | Cancellation token                                                                 |
-
-### Using aggregate identity from state
-
-This function supports storing aggregates with identity-aware state (`State<TId>`) and uses the aggregate `State.Id` property combined with the stream name map to resolve the stream name. If the stream name map is not supplied, it will use convention-based stream name calculation.
-
-```csharp
-Task<AppendEventsResult> IEventWriter.StoreAggregate<TAggregate, TState, TId>(
-    TAggregate        aggregate,
-    StreamNameMap?    streamNameMap     = null,
-    AmendEvent?       amendEvent        = null,
-    CancellationToken cancellationToken = default
-)
-```
+The connector is running continuously, and it copies all the events from the hot store to the archive store. It subscribes to the hot store using a catch-up subscription to the global log, and copies all the events from there to the archive. In this example, we use the [Elastic Connector](https://connector.eventuous.dev) in `producer` mode to replicate events from the hot store to archive store.
+
+<ThemedImage
+    alt="Replication process"
+    lightSrc={replication}
+    darkSrc={replicationDark}
+/>
 
-| Parameter           | Type                             | Description                                                                        |
-|---------------------|----------------------------------|------------------------------------------------------------------------------------|
-| `aggregate`         | `TAggregate<TState, TId>`        | Aggregate instance                                                                 |
-| `streamNameMap`     | `StreamNameMap`                  | [Map](../aggregate-stream#aggregate-streams) between identities and stream names |
-| `amendEvent`        | `Func<StreamEvent, StreamEvent>` | Function that allows adding things like custom metadata                            |
-| `cancellationToken` | `CancellationToken`              | Cancellation token                                                                 |
+As the connector replicates all the events, there's no need to perform an explicit archive action when storing the events normally using the regular event store.
 
-## Loading aggregates
+### Delete events from the hot store
 
-Several extensions for `IEventReader` interface allow loading aggregates from an event store.
+Then, to ensure that old events get removed from the hot store, you need to do so on the infrastructure level. For example, you can use the KurrentDB feature to define the [stream TTL](https://docs.kurrent.io/server/latest/features/streams.html#stream-metadata) (time to live), after which the events are removed from the hot store during the [scavenge](https://docs.kurrent.io/server/latest/operations/scavenge.html) process.
 
-### Using stream name
+> Right now, there's no built-in support for setting the stream metadata using Eventuous, but it is [being built](https://github.com/Eventuous/eventuous/issues/85).
 
-This function requires a pre-calculated stream name to be provided, so it doesn't use any convention for resolving stream names. It uses the provided stream name as-is.
+When all the bits and pieces are in place, old events will be disappearing from the hot store automatically. Alternatively, you can delete old streams using some scheduled job with a pre-defined retention rules. The archive store will keep all the events forever, unless you delete them manually.
 
-```csharp
-Task<TAggregate> LoadAggregate<TAggregate, TState>(
-    StreamName                streamName,
-    bool                      failIfNotFound    = true,
-    AggregateFactoryRegistry? factoryRegistry   = null,
-    CancellationToken         cancellationToken = default
-)
+### Aggregate store with archive
+
+Now, we need to tell Eventuous to use the archive store. It's done using the `AggregateStore<T>` class, where `T` is the archive event reader. To register an aggregate store that uses KurrentDB as the hot store and Elastic for archive, use the following code:
+
+> Elastic is a particularly good candidate for the archive store because it has multi-tier architecture as a native feature, and you can easily set up a cluster with warm, cold, and frozen tiers, so that you pay less to keep the historical events.
+
+```csharp title="Program.cs"
+// register KurrentDBClient
+// register IElasticClient
+builder.Services.AddAggregateStore<KurrentDBEventStore, ElasticEventStore>();
 ```
 
-| Parameter           | Type                       | Description                                                                                                                                                     |
-|---------------------|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `streamName`        | `StreamName`               | Aggregate stream name                                                                                                                                           |
-| `failIfNotFound`    | `bool`                     | When set to `true`, the function will throw an `AggregateNotFound` exception if the stream cannot be found. Otherwise, it will return a new aggregate instance. |
-| `factoryRegistry`   | `AggregateFactoryRegistry` | Optional aggregate factory registry, which is used to create new aggregate instances. If not supplied, the default registry is used.                            |
-| `cancellationToken` | `CancellationToken`        | Cancellation token                                                                                                                                              |
-
-### Using aggregate id
-
-This function uses the stream name map to convert the provided aggregate identity to a stream name. If the stream name map is not supplied, it will use the default, convention-based calculation (`TypeName-Id`).
-
-```csharp
-Task<TAggregate> IEventWriter.LoadAggregate<TAggregate, TState, TId>(
-    TId                       aggregateId,
-    StreamNameMap?            streamNameMap     = null,
-    bool                      failIfNotFound    = true,
-    AggregateFactoryRegistry? factoryRegistry   = null,
-    CancellationToken         cancellationToken = default
-)
+The Elastic event reader needs to have a pre-configured index. You'd need to call the following from the bootstrap code:
+
+```csharp title="Program.cs"
+var indexConfig = new IndexConfig { ... };
+var app = builder.Build();
+await app.Services.GetRequiredService<IElasticClient>()
+    .CreateIndexIfNecessary<PersistedEvent>(indexConfig);
 ```
 
-| Parameter           | Type                       | Description                                                                                                                                                     |
-|---------------------|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `id`                | `TId`                      | Aggregate identity                                                                                                                                              |
-| `streamNameMap`     | `StreamNameMap`            | [Map](../aggregate-stream#aggregate-streams) between identities and stream names                                                                              |
-| `failIfNotFound`    | `bool`                     | When set to `true`, the function will throw an `AggregateNotFound` exception if the stream cannot be found. Otherwise, it will return a new aggregate instance. |
-| `factoryRegistry`   | `AggregateFactoryRegistry` | Optional aggregate factory registry, which is used to create new aggregate instances. If not supplied, the default registry is used.                            |
-| `cancellationToken` | `CancellationToken`        | Cancellation token                                                                                                                                              |
+:::info
+Check the [Playground example](https://github.com/Eventuous/eventuous/blob/f1ccb4175c9c951c7471c6f296faf9c5262ee344/src/Experimental/src/ElasticPlayground/ConfigureElastic.cs) to see how to configure a multi-tiered index with rollover policies.
+:::
 
-## Multi-tier store
+From there, the process of loading an aggregate is seamless from the outside, but it will work differently.
+
+<ThemedImage
+    alt="Reading from two stores"
+    lightSrc={reading}
+    darkSrc={readingDark}
+/>
 
-:::note[Deprecation notice]
-Since version **0.15**, aggregate store with archive is superseded by [tiered event store](../event-store#event-store-with-archive).
+Here's the reading process described step-by-step:
+1) First, read the stream from the hot store
+2) If the stream doesn't exist, read all the stream events from the archive store
+3) If the stream exists, check the first retrieved event number
+4) If the number is greater than zero, it means that part of the stream was truncated, so read the rest of the stream from the archive store
+5) Combine events from both stores in one collection
+6) Select only distinct events using the event version
+7) Rehydrate the aggregate using the resulting events collection
+
+As the result, the load operation would be as fast as it would be with the hot store, because when the hot store returns a full stream, the aggregate store won't fall back to the archive store. However, when the aggregate store discovers that the hot store contains an incomplete stream, it will attempt to load the historical events from the archive store. As this process is seamless for the user of the aggregate store, there's no difference on the aggregate store signature.
+
+:::caution
+There is a drawback to this approach. As events disappear from the hot store, you won't be able to replay them when you create new subscriptions that need to process all the historical events. However, you need to carefully examine if this is a problem in your application.
+:::
+
+In many cases, replaying the full history is the opposite of what you want. If you add a new subscription to host a new [read model](../../read-models/rm-concept), that new read model might only need to process the latest events, and processing the full history would just trigger useless database operations.
+
+For example, if you add an _Upcoming check-ins_ read model, it would need to process events from reservations during the booking period that hasn't completed yet. It's not often that you have reservations that are made five years back, in many cases it's just impossible as hotels set their prices only a year or so upfront. Therefore, projecting the full history of reservations would trigger adding and removing thousands of records to the database, which is not what you want. In fact, if you have only reservation events for the past year, and the rest in the archive, you will have the new read model rebuilt much faster, and the fact that all the historical events are archived won't be noticeable.
+
+:::note
+Remember that you might decide to use the archive function in your system if you expect it to produce tens of millions events per year, and keep them forever.
 :::
diff --git a/docs/src/content/docs/persistence/aggregate-stream.md b/docs/src/content/docs/persistence/aggregate-stream.md
index d88e94ca3..c9bf41b92 100644
--- a/docs/src/content/docs/persistence/aggregate-stream.md
+++ b/docs/src/content/docs/persistence/aggregate-stream.md
@@ -1,6 +1,6 @@
 ---
-title: "Entity stream"
-description: "State as a stream of events"
+title: "Aggregate stream"
+description: "Aggregate as a stream of events"
 sidebar:
   order: 1
 ---
@@ -15,29 +15,20 @@ When appending events to a stream, the append operation for a single stream must
 
 ## Stream name
 
-As a stream is a boundary for a single entity state, its name must be unique per entity. Therefore, the stream name usually consists of an identifiable class name associated with the entity state (aggregate type name, state type name) without suffixes like `Aggregate`, `Entity` or `State`, combined with the entity id. Eventuous uses a convention to separate those two with a dash.
+By default, Eventuous uses the `AggregateType.Name` combined with the aggregate id as the stream name. For example, the `Booking` aggregate with id `1` has a stream name `Booking-1`. That's what `StreamName.For<Booking>(1)` returns.
 
-For example, for an entity called `Booking` where it might be represented as a `Booking` aggregate or `BookingState` state record, the stream name will start with `Booking-` followed by the entity id. So, a booking with id `123` will have a stream name `Booking-123`.
-
-### Aggregate streams
-
-For aggregates, Eventuous uses the `AggregateType.Name` combined with the aggregate id as the stream name. When using an aggregate-based command service, each command handler defines how the aggregate id is resolved from a command:
-
-```csharp
-On<ImportBooking>()
-    .InState(ExpectedState.New)
-    .GetId(cmd => new(cmd.BookingId))
-    .Act((booking, cmd) => booking.Import(cmd.RoomId, new(cmd.CheckIn, cmd.CheckOut), new(cmd.Price)));
-```
-
-In the example above, if the `ImportBooking.BookingId` property has a value `123`, the service will construct a `BookingId` instance with value `123`. Then, the service will use `StreamName.For<Booking>(id)` where `id` is of type `BookingId` to determine the stream name. Following the example, it will use `Booking-123` as the stream name, where `Booking` is the aggregate type name, and `123` is the aggregate identity value as string.
-
-However, you might want to have more fine-grained control over the stream name. For example, you might want to include the tenant id in the stream name. It's possible to override the default convention by configuring the stream name mapping. The stream map contains a mapping between the aggregate identity type (derived from `Id`) and the stream name generation function. Therefore, any additional property of the aggregate identity type can be used to generate the stream name.
+However, you might want to have more fine-grained control over the stream name. For example, you might want to include the tenant id in the stream name. It's possible to override the default convention by configuring the stream name mapping. The stream map contains a mapping between the aggregate identity type (derived from `AggregateId`) and the stream name generation function. Therefore, any additional property of the aggregate identity type can be used to generate the stream name.
 
 For example, the following code registers a stream name mapping for the `Booking` aggregate:
 
 ```csharp title="BookingId.cs"
-public record BookingId(string Value, string Tenant) : Id(Value);
+public record BookingId : AggregateId {
+    public BookingId(string id, string tenantId) : base(id) {
+        TenantId = tenantId;
+    }
+
+    public string TenantId { get; }
+}
 ```
 
 Create a `StreamNameMap` and register in the container:
@@ -45,86 +36,24 @@ Create a `StreamNameMap` and register in the container:
 ```csharp title="Program.cs"
 var streamNameMap = new StreamNameMap();
 streamNameMap.Register<BookingId>(
-    id => new StreamName($"Booking-{id.Tenant}:{id.Value}") 
+    id => new StreamName($"Booking-{id.TenantId}:{id.Value}") // Split in example with : if you use a Guid as identifier.
 );
 builder.Services.AddSingleton(streamNameMap);
-builder.Services.AddCommandService<BookingService, BookingState>();
+builder.Services.AddCommandService<BookingService, Booking>();
 ```
 
 Then, use the registered `StreamNameMap` in the `CommandService`:
 
 ```csharp title="BookingService.cs"
-// Aggregate service
 public class BookingService : CommandService<Booking, BookingState, BookingId> {
-    public BookingService(IEventStore store, StreamNameMap streamNameMap)
+    public BookingService(IAggregateStore store, StreamNameMap streamNameMap)
         : base(store, streamNameMap: streamNameMap) {
         // command handlers registered here
     }
 }
 ```
 
-### State streams
-
-State streams and aggregate streams are essentially the same. Aggregates don't persist anything else than their state. The difference from the API perspective is in how stream names are resolved by command services.
-
-While aggregate-based services calculate stream names using the aggregate type name and aggregate identity, functional services expect you to specify a function to retrieve the stream name from a command when you defined the command handler. 
-
-Let's have a look at the following command handler definition:
-
-```csharp
-// Constructor of BookingService : CommandService<BookingState>
-On<BookRoom>()
-    .InState(ExpectedState.New)
-    .GetStream(cmd => GetStream(cmd.BookingId))
-    .Act(BookRoom);
-```
-
-Here, the command service is instructed to use the default way to resolve the stream name from a command. It uses the `GetStream` function available in the command service base class, which calls `StreamName.ForState<TState>` function. By convention, it will take the `TState` type name, remove `State` word from it if it's there, and append a dash followed the entity id to the string. So, if the `BookRoom.Id` property has a value `123`, the stream name would be resolved as `Booking-123`. 
-
-## Reversing stream name to identity
-
-As you don't need to include the entity or aggregate id to the events, you might be wondering how to get the identity in, for example, downstream event handlers like read model projections. For that purpose, you'd need to resolve the identity from the stream name.
-
-### Convention-based
-
-There are several options available to determine the entity or aggregate id, which then can be used as a document id or primary key for projected models, from stream names.
-
-First, the `StreamName` struct provides the `GetId()` function that returns the convention-based identity. It takes part of the stream name string following the dash and returns it as a string. For example, if the stream name is `Booking-123`, `GetId()` will return `123`.
-
-For example, a projecting handler for MongoDB uses it like this:
-
-```csharp
-On<BookingImported>(
-    b => b
-        .InsertOne
-        .Document(
-            (stream, e) => new(stream.GetId()) {
-                RoomId       = e.RoomId,
-                CheckInDate  = e.CheckIn,
-                CheckOutDate = e.CheckOut,
-                BookingPrice = e.Price,
-                Outstanding  = e.Price
-            }
-        )
-);
-```
-
-MongoDB projections also provide a `DefaultId()` helper that also uses the convention:
-
-```csharp
-On<BookingPaymentRegistered>(
-    b => b
-        .UpdateOne
-        .DefaultId()
-        .Update((evt, update) => update.Set(x => x.PaidAmount, evt.AmountPaid))
-);
-```
-
-### Custom stream names
-
-Convention-based approach won't work if you use custom stream names. In that case, you'd need to write code to calculate the identity value from stream names.
-
-For example, your projections can retrieve the `Id` and `TenantId` from the `StreamName` in the `IMessageConsumeContext<T>`:
+In your projections you can retrieve the `Id` and `TenantId` from the `StreamName` in the `IMessageConsumeContext<out T>`:
 
 ```csharp title="BookingStateProjection.cs"
 static UpdateDefinition<BookingDocument> HandleRoomBooked(
@@ -151,24 +80,26 @@ static UpdateDefinition<BookingDocument> HandleRoomBooked(
 The snippet above uses the following extension method to extract the `Id` and `TenantId` from the `StreamName`:
 
 ```csharp title="StreamNameExtensions.cs"
-/// <summary>
-/// Split the StreamName into multiple parts for multi tenant stream id.
-/// </summary>
-/// <param name="stream">The streamname</param>
-/// <param name="separator">The seperator for splitting. Default is ':'.</param>
-/// <returns>A tuple with TenantId and Id property.</returns>
-/// <exception cref="InvalidStreamName">When stream id can't be split in 2 sections.</exception>
-public static (string TenantId, string Id) ExtractMultiTenantIds(
-    this StreamName stream, 
-    char separator = ':'
-) {
-    var streamId = stream.GetId(); // Returns "tenant:id" from "Booking-tenant:id"
-    var parts = streamId.Split(separator);
-
-    if (parts.Length != 2) {
-        throw new InvalidStreamName(streamId);
+public static class StreamNameExtensions
+{
+    /// <summary>
+    /// Split the StreamName into multiple parts for multi tenant stream id.
+    /// </summary>
+    /// <param name="stream">The streamname</param>
+    /// <param name="separator">The seperator for splitting. Default is ':'.</param>
+    /// <returns>A tuple with TenantId and Id property.</returns>
+    /// <exception cref="InvalidStreamName">When stream id can't be split in 2 sections.</exception>
+    public static (string TenantId, string Id) ExtractMultiTenantIds(this StreamName stream, char separator = ':')
+    {
+        string streamId = stream.GetId();
+        var streamIdParts = streamId.Split(separator);
+
+        if (streamIdParts.Length != 2)
+        {
+            throw new InvalidStreamName(streamId);
+        }
+
+        return (streamIdParts[0], streamIdParts[1]);
     }
-
-    return (parts[0], parts[1]);
 }
 ```
diff --git a/docs/src/content/docs/persistence/event-store.md b/docs/src/content/docs/persistence/event-store.md
new file mode 100644
index 000000000..641a2fa3d
--- /dev/null
+++ b/docs/src/content/docs/persistence/event-store.md
@@ -0,0 +1,49 @@
+---
+title: "Event store"
+description: "Event store infrastructure"
+sidebar:
+  order: 2
+---
+
+In order to isolate the core library from a particular way of storing events, Eventuous uses the `IEventStore` abstraction. Whilst it's used by `AggregateStore`, you can also use it in a more generic way, when you need to persist or read events without having an aggregate.
+
+The `IEventStore` interface inherits from `IEventReader` and `IEventWriter` interfaces. Each of those interfaces is focused on one specific task - reading events from streams, and appending events to streams. This separation is necessary for scenarios when you only need, for example, to read events from a specific store, but not to append them. In such case, you'd want to use the `IEventReader` interface only.
+
+Eventuous has several implementations of event store abstraction, you can find them in the [infrastructure](../../infra/esdb) section. The default implementation is `KurrentDBEventStore`, which uses [KurrentDB](https://kurrent.io) as the event store. It's a great product, and we're happy to provide first-class support for it. It's also a great product for learning about Event Sourcing and CQRS.
+
+In addition, Eventuous has an in-memory event store, which is mostly used for testing purposes. It's not recommended to use it in production, as it doesn't provide any persistence guarantees.
+
+### Primitives
+
+Event store works with a couple of primitives, which allow wrapping infrastructure-specific structures. Those primitives are:
+
+| Record type             | What it's for                                                                                                                                         |
+|-------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `StreamReadPosition`    | Represent the stream revision, from there the event store will read the stream forwards or backwards.                                                 |
+| `ExpectedStreamVersion` | The stream version (revision), which we expect to have in the database, when event store tries to append new events. Used for optimistic concurrency. |
+| `StreamEvent`           | A structure, which holds the event type as a string as well as serialised event payload and metadata.                                                 |
+
+All of those are immutable records.
+
+### Operations
+
+Right now, we only have four operations for an event store:
+
+| Function              | What's it for                                                                                                 |
+|-----------------------|---------------------------------------------------------------------------------------------------------------|
+| `AppendEvents`        | Append one or more events to a given stream.                                                                  |
+| `ReadEvents`          | Read events from a stream forwards, from a given start position.                                              |
+
+Eventuous has several implementations of the event store: 
+ * [KurrentDB](../../infra/esdb)
+ * [PostgreSQL](../../infra/postgres)
+ * [Microsoft SQL Server](../../infra/mssql)
+ * [SQLite](../../infra/sqlite)
+ * [Elasticsearch](../../infra/elastic)
+
+If you use one of the implementations provided, you won't need to know about the event store abstraction. It is required though if you want to implement it for your preferred database. 
+
+:::tip
+Preferring KurrentDB will save you lots of time!
+Remember to check [Kurrent Cloud](https://kurrent.io/cloud).
+:::
diff --git a/docs/src/content/docs/persistence/index.mdx b/docs/src/content/docs/persistence/index.mdx
new file mode 100644
index 000000000..e84afdd5a
--- /dev/null
+++ b/docs/src/content/docs/persistence/index.mdx
@@ -0,0 +1,13 @@
+---
+title: "Persistence"
+description: >
+  Event-sourced persistence abstractions and implementations.
+---
+
+As mentioned in the [Prologue](../prologue/introduction), Event Sourcing is a way to persist state. Therefore, the way to handle _persistence_ is one of the fundamental differences of event-sourced systems, compared with state-based systems.
+
+Read more about essential concepts of event-sourced persistence.
+
+:::info
+Make sure to read about [events serialisation](serialisation).
+:::
diff --git a/docs/src/content/docs/persistence/serialisation.md b/docs/src/content/docs/persistence/serialisation.md
index 069a5a6ca..06e12ea57 100644
--- a/docs/src/content/docs/persistence/serialisation.md
+++ b/docs/src/content/docs/persistence/serialisation.md
@@ -122,6 +122,6 @@ DefaultEventSerializer.SetDefaultSerializer(serializer);
 
 In many cases you might want to store event metadata in addition to the event payload. Normally, you'd use the same way to serialize both the event payload and its metadata, but it's not always the case. For example, you might store your events in Protobuf, but keep metadata as JSON.
 
-Eventuous only uses the metadata serializer when the event store implementation, or a producer can store metadata as a byte array. For example, EventStoreDB supports that, but Google PubSub doesn't. Therefore, the event store and producer that use EventStoreDB will use the metadata serializer, but the Google PubSub producer will add metadata to events as headers, and won't use the metadata serializer.
+Eventuous only uses the metadata serializer when the event store implementation, or a producer can store metadata as a byte array. For example, KurrentDB supports that, but Google PubSub doesn't. Therefore, the event store and producer that use KurrentDB will use the metadata serializer, but the Google PubSub producer will add metadata to events as headers, and won't use the metadata serializer.
 
 For the metadata serializer the same principles apply as for the event serializer. Eventuous has a separate interface `IMetadataSerializer`, which has a default instance created on startup by implicitly. You can register a custom metadata serializer as a singleton or override the default one by calling `DefaultMetadataSerializer.SetDefaultSerializer` function. 
diff --git a/docs/src/content/docs/producers/implementation.md b/docs/src/content/docs/producers/implementation.md
index 94cfbad5b..d68a4a568 100644
--- a/docs/src/content/docs/producers/implementation.md
+++ b/docs/src/content/docs/producers/implementation.md
@@ -1,8 +1,8 @@
 ---
 title: "Implementation"
-sidebar:
-  order: 100
 description: "How producers are implemented"
+sidebar:
+  order: 1
 ---
 
 ## Abstraction
@@ -53,16 +53,16 @@ public record ProducedMessage {
 
 The `Message` property represents the actual message payload. Producers typically use an `IEventSerializer` instance to serialize the message payload. However, in certain situations, producers may need to comply with their supporting infrastructure and use a different method for serializing the message payload. In such cases, the `MessageType property can be included in the produced message body or header, allowing for proper deserialization by subscribers.
 
-As base producer is responsible for tracing, it creates the produce span and set some tags for it. Learn more on the [Diagnostics](../../diagnostics/traces) page. The base producer is unaware of the message type, and if the producer implementation wants to set the message type as a span tag, it should call the `SetActivityMessageType` method of the base class. All bundled producers do that except Elasticsearch producer.
+As base producer is responsible for tracing, it creates the produce span and set some tags for it. Learn more on the [Diagnostics](../../diagnostics/details) page. The base producer is unaware of the message type, and if the producer implementation wants to set the message type as a span tag, it should call the `SetActivityMessageType` method of the base class. All bundled producers do that except Elasticsearch producer.
 
 ## Registration
 
 Eventuous provides several extensions to the `IServiceCollection` interface to register producers. You can provide a pre-made producer instance, a function to resolve the producer from the `IServiceProvider`, or simply the producer type if its dependencies can be resolved automatically.
 
-For instance, if you have already registered the `EventStoreClient` instance, you can register the `EventStoreProducer` as follows:
+For instance, if you have already registered the `KurrentDBClient` instance, you can register the `KurrentDBProducer` as follows:
 
 ```csharp title="Program.cs"
-builder.Services.AddProducer<EventStoreProducer>();
+builder.Services.AddProducer<KurrentDBProducer>();
 ```
 
 If a producer requires some work to be done before it is ready, it should implement the `IHostedProducer` interface, allowing it to perform necessary startup tasks in its `StartAsync` method. When using any of the `AddProducer` extensions, if the producer implements `IHostedProducer`, it will be registered as such.
diff --git a/docs/src/content/docs/producers/index.mdx b/docs/src/content/docs/producers/index.mdx
index 8241bb0a0..d348f5182 100644
--- a/docs/src/content/docs/producers/index.mdx
+++ b/docs/src/content/docs/producers/index.mdx
@@ -1,8 +1,6 @@
 ---
 title: "Producers"
 description: "Message producers"
-sidebar:
-  order: 700
 ---
 
 Producers, along with [Subscriptions](../subscriptions/subs-concept), are the foundation of the Eventuous' messaging system.
diff --git a/docs/src/content/docs/producers/providers.md b/docs/src/content/docs/producers/providers.md
index f4a5f8502..9d2bd8e77 100644
--- a/docs/src/content/docs/producers/providers.md
+++ b/docs/src/content/docs/producers/providers.md
@@ -5,7 +5,7 @@ description: "List of producers available in Eventuous"
 
 Eventuous supports the following producers:
 
-- [EventStoreDB](../../infra/esdb#producer)
+- [KurrentDB](../../infra/esdb#producer)
 - [Apache Kafka](../../infra/kafka#producer)
 - [RabbitMQ](../../infra/rabbitmq#producer)
 - [Google PubSub](../../infra/pubsub#producer)
diff --git a/docs/src/content/docs/prologue/introduction.md b/docs/src/content/docs/prologue/introduction.md
index 55336b333..465341f30 100644
--- a/docs/src/content/docs/prologue/introduction.md
+++ b/docs/src/content/docs/prologue/introduction.md
@@ -13,12 +13,12 @@ Eventuous is a (relatively) lightweight library, which allows building productio
 The base library has a set of abstractions, following Domain-Driven Design tactical patterns, like `Aggregate`.
 
 Additional components include:
-- [Aggregate persistence](../../persistence) using [EventStoreDB](https://eventstore.com), PostgreSQL, and Microsoft SQL Server
-- [Real-time subscriptions](../../subscriptions/subs-concept) for EventStoreDB, PostgreSQL, Microsoft SQL Server, RabbitMQ, and Google PubSub
+- [Aggregate persistence](../../persistence) using [KurrentDB](https://kurrent.io), PostgreSQL, Microsoft SQL Server, and SQLite
+- [Real-time subscriptions](../../subscriptions/subs-concept) for KurrentDB, PostgreSQL, Microsoft SQL Server, SQLite, RabbitMQ, and Google PubSub
 - [Command services](../../application) and HTTP-based commands
 - Extensive observability, including Open Telemetry support
 - Integration with ASP.NET Core dependency injection, logging, and Web API
-- [Producers](../../producers) for EventStoreDB, RabbitMQ, Google PubSub, and Apache Kafka
+- [Producers](../../producers) for KurrentDB, RabbitMQ, Google PubSub, and Apache Kafka
 - [Read model](../../read-models/rm-concept) projections for MongoDB
 - [Gateway](../../gateway) for producing events to other services (Event-Driven Architecture support)
 
@@ -43,9 +43,10 @@ You can find all the NuGet packages by visiting the [Eventuous profile](https://
 | `Eventuous.Diagnostics.OpenTelemetry` | Diagnostics integration with [OpenTelemetry](https://opentelemetry.io/)                                    |
 | `Eventuous.Diagnostics.Logging`       | Eventuous internal logs adapter for ASP.NET Core logging                                                   |
 | `Eventuous.Gateway`                   | Eventuous [gateway](../../gateway) for connecting subscriptions with producers                                |
-| `Eventuous.EventStore`                | Support for [EventStoreDB](../../infra/esdb) (event store, subscriptions, producers)                          |
+| `Eventuous.KurrentDB`                 | Support for [KurrentDB](../../infra/esdb) (event store, subscriptions, producers)                             |
 | `Eventuous.Postgresql`                | Support for [PostgreSQL](../../infra/postgres) (event store, subscriptions, producers)                        |
 | `Eventuous.SqlServer`                 | Support for [Microsoft SQL Server](../../infra/mssql) (event store, subscriptions, producers)                 |
+| `Eventuous.Sqlite`                    | Support for [SQLite](../../infra/sqlite) (event store, subscriptions, projections)                            |
 | `Eventuous.RabbitMq`                  | Support for RabbitMQ (subscriptions, producers)                                                            |
 | `Eventuous.GooglePubSub`              | Support for Google PubSub (subscriptions, producers)                                                       |
 | `Eventuous.Kafka`                     | Support for Apache Kafka (producers)                                                                       |
diff --git a/docs/src/content/docs/prologue/quick-start.md b/docs/src/content/docs/prologue/quick-start.md
index 7c6c40617..5892a7665 100644
--- a/docs/src/content/docs/prologue/quick-start.md
+++ b/docs/src/content/docs/prologue/quick-start.md
@@ -6,7 +6,7 @@ sidebar:
 ---
 
 You can find a bookings sample application here:
-- [.NET EventStoreDB write => MongoDB read](https://github.com/Eventuous/eventuous/tree/dev/samples/esdb)
+- [.NET KurrentDB write => MongoDB read](https://github.com/Eventuous/eventuous/tree/dev/samples/kurrentdb)
 - [.NET PostgreSQL write => MongoDB read](https://github.com/Eventuous/eventuous/tree/dev/samples/postgres)
 
 Samples are being updated with the latest features and improvements.
diff --git a/docs/src/content/docs/prologue/the-right-way.mdx b/docs/src/content/docs/prologue/the-right-way.mdx
index e4cfcd202..2cdb295a1 100644
--- a/docs/src/content/docs/prologue/the-right-way.mdx
+++ b/docs/src/content/docs/prologue/the-right-way.mdx
@@ -4,7 +4,9 @@ description: >
     Event Sourcing done right, as it meant to be. Don't get caught up in the misconception that Event Sourcing is the same thing
     as Event-Driven Architecture.
 ---
-import ThemedImage from '../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import theRightWay from './images/the-right-way.png';
+import theRightWayDark from './images/the-right-way-dark.png';
 
 If you've ever searched for a diagram that explains Event Sourcing, you may have found many images, but most of them are confusing or simply incorrect. Despite claims that Event Sourcing is difficult, many people who have this opinion have never actually tried it or made mistakes during implementation.
 
@@ -26,8 +28,8 @@ Please refer to the diagram below for a complete understanding of the process.
 
 <ThemedImage
     alt="Eventuous way"
-    lightSrc="./images/the-right-way.png"
-    darkSrc="./images/the-right-way-dark.png"
+    lightSrc={theRightWay}
+    darkSrc={theRightWayDark}
 />
 
 ## What's wrong with those other diagrams?
diff --git a/docs/src/content/docs/read-models/rm-concept.md b/docs/src/content/docs/read-models/rm-concept.md
index 92363d1b7..e3715ef03 100644
--- a/docs/src/content/docs/read-models/rm-concept.md
+++ b/docs/src/content/docs/read-models/rm-concept.md
@@ -61,7 +61,7 @@ Built as read models, all those queries can be run in a single query, without th
 
 For building read models, you need to receive events from the event store and project them real time to a queryable store. Let's say that we have two event types:
 
-```
+```csharp
 record RoomBooked(
     string BookingsId,
     string RoomId,
@@ -123,10 +123,10 @@ In some cases, you have a requirement that the query model needs to be updated _
 
 ### Stop forgetting things
 
-Not all user interfaces are built stateless. With the rise of single-page application frameworks such as React and VueJS, the user's browser holds quite a lot of state. That state can be used for remembering things. Think about that form again, haven't you got the [new entity state](../../application/app-service#result) from Eventuous after calling the HTTP API? Why can't it be used to update the existing client-side application state instead of querying it from the server again? When using state management tools like Redux or VueX you can even propagate events received in the `Result` object to the client-side application state using the store reducers (which are, effectively, event handlers). This way, you can even improve the cohesiveness of the whole system by letting its front- and back-end to use the same events, using the same Ubiquitous Language.
+Not all user interfaces are built stateless. With the rise of single-page application frameworks such as [React](https://react.dev) and [Vue](https://vuejs.org), the user's browser holds quite a lot of state. That state can be used for remembering things. Think about that form again, haven't you got the [new entity state](../../application/app-service#result) from Eventuous after calling the HTTP API? Why can't it be used to update the existing client-side application state instead of querying it from the server again? When using state management tools like [Redux](https://redux.js.org/) or [Vuex](https://vuex.vuejs.org) you can even propagate events received in the `Result` object to the client-side application state using the store reducers (which are, effectively, event handlers). This way, you can even improve the cohesiveness of the whole system by letting its front- and back-end to use the same events, using the same Ubiquitous Language.
 
 ### Wait
 
 Sometimes you can't control the UI, but you do control the query API, and you know that the UI works in the form-list fashion. There's a clear risk that when the user gets redirected to the list after submitting the form, they won't find the new or updated information in the list. In that case, you can use the command handling result combined with the projected item `Position` property. For example, the [MongoDB projection](../../infra/mongodb) implicitly updates the read model document `Position` property with the projected event global log position. When the command is handled successfully by the command service, you get the `OkResult` record instance back. There, you find the `StreamPosition` property, which points to the last appended event global position. You can then query your read model store for a specific read model that feeds the list where the user will be redirected to. When you find out that the document in that read model got updated with the `Position` property higher or equal the returned `StreamPosition` value, you can return `200 OK` result to the API call. Until then, you just wait. By doing this, you will ensure that the list that the user will see after handling the command will contain the updated information.
 
-You can also query the checkpoint store for a given read model to see if the stored checkpoint surpasses the one you get in the `OkResult` object. But then, you need to be sure that the subscription is listening to the global event stream (it won't work if you use, for example, the category stream in EventStoreDB), and the checkpoint is not batched (it's batched by default). We don't recommend using this approach.
+You can also query the checkpoint store for a given read model to see if the stored checkpoint surpasses the one you get in the `OkResult` object. But then, you need to be sure that the subscription is listening to the global event stream (it won't work if you use, for example, the category stream in KurrentDB), and the checkpoint is not batched (it's batched by default). We don't recommend using this approach.
diff --git a/docs/src/content/docs/read-models/supported-projectors.md b/docs/src/content/docs/read-models/supported-projectors.md
index 590dd4f1c..f4be32425 100644
--- a/docs/src/content/docs/read-models/supported-projectors.md
+++ b/docs/src/content/docs/read-models/supported-projectors.md
@@ -8,5 +8,6 @@ Eventuous supports the following projection targets:
 - [MongoDB projections](../../infra/mongodb)
 - [PostgreSQL projections](../../infra/postgres#projections)
 - [Microsoft SQL Server projections](../../infra/mssql#projections)
+- [SQLite projections](../../infra/sqlite#projections)
 
 You can project to any other database using a custom projector, which can be built as a [custom event handler](../../subscriptions/eventhandler#custom-handlers).
\ No newline at end of file
diff --git a/docs/src/content/docs/subscriptions/checkpoint.mdx b/docs/src/content/docs/subscriptions/checkpoint.mdx
index 8d3334e23..d0e689c86 100644
--- a/docs/src/content/docs/subscriptions/checkpoint.mdx
+++ b/docs/src/content/docs/subscriptions/checkpoint.mdx
@@ -2,7 +2,9 @@
 title: "Checkpoints"
 description: "What's a checkpoint and why you need to store it"
 ---
-import ThemedImage from '../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import commitHandler from './images/commit-handler.png';
+import commitHandlerDark from './images/commit-handler-dark.png';
 
 When subscribing to an event store, it is important to consider which events you wish to receive. An effective event store should allow you to subscribe to individual event streams or to a global stream known as the "All stream", which contains all events in the store, organized in the order they were recorded. Many event-driven brokers that persist events as ordered logs also support subscriptions, which are often referred to as "consumers".
 
@@ -12,7 +14,7 @@ The subscription you choose will determine at what point in the stream you begin
 
 As the subscription receives and processes events, it progresses along the subscribed stream. Each event that is received and processed has a unique position within the stream, which serves as a checkpoint for the subscription. If the application hosting the subscription shuts down, it is necessary to resume processing events from the last recorded checkpoint, which is the position of the last processed event plus one. This ensures that each event is handled exactly once. As a result, the subscription must keep track of its checkpoint, either by storing it in a dedicated checkpoint store or by using the event store's built-in functionality.
 
-In some log-based brokers, the concept of a checkpoint is referred to as an "offset". Some event-driven brokers manage subscriptions on the server-side, eliminating the need for client-side checkpoint storage. For example, persistent subscriptions in EventStoreDB and subscriptions in Google PubSub do not require a client-side checkpoint store. Other subscriptions, such as those managed by RabbitMQ, do not have the concept of a checkpoint as RabbitMQ does not retain consumed messages, whether they have been acknowledged or not.
+In some log-based brokers, the concept of a checkpoint is referred to as an "offset". Some event-driven brokers manage subscriptions on the server-side, eliminating the need for client-side checkpoint storage. For example, persistent subscriptions in KurrentDB and subscriptions in Google PubSub do not require a client-side checkpoint store. Other subscriptions, such as those managed by RabbitMQ, do not have the concept of a checkpoint as RabbitMQ does not retain consumed messages, whether they have been acknowledged or not.
 
 ## Checkpoint store
 
@@ -89,11 +91,15 @@ The Postgres checkpoint store will create and use the `checkpoint` table, and th
 
 ```sql
 create table if not exists __schema__.checkpoints (
-    id varchar primary key, 
-    position bigint null 
+    id varchar primary key,
+    position bigint null
 );
 ```
 
+#### SQLite
+
+The SQLite checkpoint store uses a `{schema}_checkpoints` table (default: `eventuous_checkpoints`), with the subscription id as the row key. The table is created automatically when `initializeDatabase: true` is set.
+
 #### Other stores
 
 In addition to that, Eventuous has two implementations in the core subscriptions package:
@@ -102,6 +108,28 @@ In addition to that, Eventuous has two implementations in the core subscriptions
 
 The measured store is used by default if Eventuous diagnostics aren't disabled, and you use the `AddCheckpointStore` container registration extension.
 
+## Initial position
+
+When a subscription starts for the first time and no checkpoint exists, it needs to decide where to begin reading events. By default, subscriptions start from the **earliest** position (the beginning of the stream). You can change this behaviour using the `StartFrom` option on any subscription that uses checkpoints:
+
+```csharp
+builder.Services.AddSubscription<MySubscription, MySubscriptionOptions>(
+    "MySubscription",
+    b => b
+        .Configure(cfg => cfg.StartFrom = InitialPosition.Latest)
+        .AddEventHandler<MyHandler>()
+);
+```
+
+| Value | Description |
+|---|---|
+| `InitialPosition.Earliest` | Start from the beginning of the stream (default). Processes all historical events. |
+| `InitialPosition.Latest` | Start from the current end of the stream. Only processes events produced after the subscription starts. |
+
+:::note
+The `StartFrom` option only applies when there is no existing checkpoint. Once a checkpoint is stored, the subscription always resumes from the last committed checkpoint position, regardless of the `StartFrom` setting.
+:::
+
 ## Checkpoint commit handler
 
 In addition to checkpoint store, Eventuous has a more advanced way to work with checkpoints. It doesn't load or store checkpoints by itself, for that purpose it uses the provided checkpoint store. However, the commit handler is able to receive a stream of unordered checkpoints, reorder them, detect possible gaps, and only store the checkpoint that is the latest before the gap.
@@ -114,8 +142,8 @@ When events get partitioned by the filter, several consumer instances process ev
 
 <ThemedImage
     alt="Gap in the commit handler queue"
-    lightSrc="./images/commit-handler.png"
-    darkSrc="./images/commit-handler-dark.png"
+    lightSrc={commitHandler}
+    darkSrc={commitHandlerDark}
 />
 
 :::note
diff --git a/docs/src/content/docs/subscriptions/pipes.mdx b/docs/src/content/docs/subscriptions/pipes.mdx
index a280a4be6..891cd03a0 100644
--- a/docs/src/content/docs/subscriptions/pipes.mdx
+++ b/docs/src/content/docs/subscriptions/pipes.mdx
@@ -1,10 +1,14 @@
 ---
 title: "Consume pipe"
 description: "Subscription consume pipes and filters"
-sidebar:
-  order: 527
 ---
-import ThemedImage from '../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import defaultPipe from './images/default-pipe.png';
+import defaultPipeDark from './images/default-pipe-dark.png';
+import concurrentFilter from './images/concurrent-filter.png';
+import concurrentFilterDark from './images/concurrent-filter-dark.png';
+import partitioningFilter from './images/partitioning-filter.png';
+import partitioningFilterDark from './images/partitioning-filter-dark.png';
 
 ## Pipes and filters
 
@@ -14,11 +18,11 @@ Eventuous consume pipe can be customised by adding filters to it, but normally y
 
 <ThemedImage
     alt="Default consume pipeline"
-    lightSrc="./images/default-pipe.png"
-    darkSrc="./images/default-pipe-dark.png"
+    lightSrc={defaultPipe}
+    darkSrc={defaultPipeDark}
 />
 
-Some subscriptions conditionally or unconditionally add filters to the pipe, when they detect the default pipe. For example, EventStoreDB catch-up subscription might add the concurrent filter and partitioning filter, and RabbitMQ subscription uses the concurrent filter.
+Some subscriptions conditionally or unconditionally add filters to the pipe, when they detect the default pipe. For example, KurrentDB catch-up subscription might add the concurrent filter and partitioning filter, and RabbitMQ subscription uses the concurrent filter.
 
 ## Available filters
 
@@ -64,12 +68,12 @@ The tracing filter gets added automatically when Eventuous diagnostics is enable
 
 When using the concurrent filter, the pipe gets separated in two parts: before the concurrent filter and after it. The filter itself creates a channel of a given size (100 by default), where it puts all the messages in order. Then, the pipeline returns to the subscription as if the message was already consumed. A parallel process fetches messages from the channel continuously, and sends them to the second part of the pipe where messages actually gets consumed.
 
-Because of such a split, the result returned to the subscription doesn't contain the actual handling result. Therefore, the concurrent filter can only be used in combination with `DelayedAckConsumeContext`. It's the responsibility of a subscription to create such a context type, so only some subscription types support using the concurrent filter. This context type has two additional functions to Ack (`Acknowledge` function) or Nack (`Fail` function) each message. The subscription provides specific implementations of those functions. For example, an EventStoreDB catch-up subscription would commit the checkpoint when the event is acknowledged. The filter calls these functions itself, based on the result returned by the second part of the pipe (delayed consume).
+Because of such a split, the result returned to the subscription doesn't contain the actual handling result. Therefore, the concurrent filter can only be used in combination with `DelayedAckConsumeContext`. It's the responsibility of a subscription to create such a context type, so only some subscription types support using the concurrent filter. This context type has two additional functions to Ack (`Acknowledge` function) or Nack (`Fail` function) each message. The subscription provides specific implementations of those functions. For example, a KurrentDB catch-up subscription would commit the checkpoint when the event is acknowledged. The filter calls these functions itself, based on the result returned by the second part of the pipe (delayed consume).
 
 <ThemedImage
     alt="Pipe with concurrent filter"
-    lightSrc="./images/concurrent-filter.png"
-    darkSrc="./images/concurrent-filter-dark.png"
+    lightSrc={concurrentFilter}
+    darkSrc={concurrentFilterDark}
 />
 
 The concurrent filter is useful in combination with partitioning filter, but it can also be used for other purposes, like batched event processing.
@@ -86,8 +90,8 @@ Sometimes the subscription workload gets too high for it to cope with the number
 
 <ThemedImage
     alt="Pipe with concurrent and partitioning filters"
-    lightSrc="./images/partitioning-filter.png"
-    darkSrc="./images/partitioning-filter-dark.png"
+    lightSrc={partitioningFilter}
+    darkSrc={partitioningFilterDark}
 />
 
 You can use two options for configuring the filter:
diff --git a/docs/src/content/docs/subscriptions/sub-base.md b/docs/src/content/docs/subscriptions/sub-base.md
index 26151d198..e856af6ac 100644
--- a/docs/src/content/docs/subscriptions/sub-base.md
+++ b/docs/src/content/docs/subscriptions/sub-base.md
@@ -80,7 +80,7 @@ The subscription will acknowledge the event only if all of its handlers _don't f
 
 ## Registration
 
-As mentioned before, you'd normally register subscriptions using the DI extensions provided by Eventuous. This example uses the [EventStoreDB](../../infra/esdb) subscription.
+As mentioned before, you'd normally register subscriptions using the DI extensions provided by Eventuous. This example uses the [KurrentDB](../../infra/esdb) subscription.
 
 ```csharp title="Program.cs"
 builder.Services.AddSubscription<StreamSubscription, StreamSubscriptionOptions>(
diff --git a/docs/src/content/docs/subscriptions/subs-concept.mdx b/docs/src/content/docs/subscriptions/subs-concept.mdx
index 8e15a5dc7..e014f6506 100644
--- a/docs/src/content/docs/subscriptions/subs-concept.mdx
+++ b/docs/src/content/docs/subscriptions/subs-concept.mdx
@@ -4,7 +4,9 @@ description: "The concept of real-time subscriptions"
 sidebar:
   order: 1
 ---
-import ThemedImage from '../../../components/ThemedImage.astro';
+import ThemedImage from '@components/ThemedImage.astro';
+import subscriptions from './images/subscriptions.png';
+import subscriptionsDark from './images/subscriptions-dark.png';
 
 Real-time subscriptions are essential when building a successful event-sourced system. They support the following sequence of operations:
 
@@ -31,7 +33,7 @@ By combining those two projections in _one subscription_, they could be both beh
 
 Subscriptions need to maintain their own [checkpoints](../checkpoint), so when the service that host a subscription restarts, it will start receiving events from the last known position in the stream.
 
-Most often, you'd want to subscribe to the _global event stream_, so you can build read models, which compose information from different aggregates. Eventuous offers the [All stream subscription](../../infra/esdb/#all-stream-subscription) for this use case. In some cases you'd need to subscribe to a regular stream using the [stream subscription](../../infra/esdb/#single-stream-subscription).
+Most often, you'd want to subscribe to the _global event stream_, so you can build read models, which compose information from different aggregates. Eventuous offers the [All stream subscription](../../infra/esdb#all-stream-subscription) for this use case. In some cases you'd need to subscribe to a regular stream using the [stream subscription](../../infra/esdb#single-stream-subscription).
 
 In Eventuous, subscriptions are specific to event store implementation. In addition, Eventuous has subscriptions to message brokers like Google PubSub and RabbitMQ for integration purposes.
 
@@ -40,7 +42,7 @@ In Eventuous, subscriptions are specific to event store implementation. In addit
 One of the common mistakes people make when building an event-sourced application is using an event store which is not capable of handling realtime subscriptions. It forces developers to engage some sort of message bus to deliver new events to subscribers. There are [quite a few issues](../../prologue/the-right-way) with that approach, but the most obvious one is a two-phase commit.
 
 :::tip[Bad bus]
-Read more about the **[Bad Bus →](../../prologue/the-right-way/#event-bus)**
+Read more about the **[Bad Bus →](../../prologue/the-right-way#event-bus)**
 :::
 
 When using two distinct pieces of infrastructure in one transaction, you risk one of those operations to fail. Let's use the following example code, which is very common:
@@ -54,7 +56,7 @@ If the second operation fails, the command side of the application would remain
 
 As mentioned, there are multiple issues of using a message bus as transport to deliver events to reporting models, but we won't be covering them on this page.
 
-The easiest way to solve the issue is to use a database which supports realtime subscriptions to event streams out of the box. That's why we use EventStoreDB as the primary event store implementation.
+The easiest way to solve the issue is to use a database which supports realtime subscriptions to event streams out of the box. That's why we use KurrentDB as the primary event store implementation.
 
 ## The right way
 
@@ -62,8 +64,8 @@ It is not hard to avoid the two-phase commits and ensure to publish domain event
 
 <ThemedImage
     alt="Consistent event flow"
-    lightSrc="./images/subscriptions.png"
-    darkSrc="./images/subscriptions-dark.png"
+    lightSrc={subscriptions}
+    darkSrc={subscriptionsDark}
 />
 
 Why is this flow "consistent"? It's because the command handling process always finishes with an append operation towards event store (unless the command fails). There's no explicit `Publish` or `Produce` call that happens after the event is persisted. A proper event store should have a capability for to subscribe for getting all the new events when they appear in the store. As the `Append` operation of the event store is transactional, such a subscription will get the event only once, if it is capable to acknowledge the event correctly back to the subscription.
diff --git a/docs/src/content/docs/subscriptions/subs-diagnostics.md b/docs/src/content/docs/subscriptions/subs-diagnostics.md
index 936fd9e1e..2f346b596 100644
--- a/docs/src/content/docs/subscriptions/subs-diagnostics.md
+++ b/docs/src/content/docs/subscriptions/subs-diagnostics.md
@@ -35,7 +35,7 @@ Eventuous collects two types of metrics for subscriptions:
 
 For the subscription gap, Eventuous collects the time and count of the gap between the last event in the stream, which the subscription listens to, and the event, which is currently being processed.
 
-Keep in mind that due to the limitation of EventStoreDB, the gap event count is not accurate when subscribing to `$all` stream. It's because the `$all` stream position is the commit position of the event in the global log, not the position of the event in the stream. Unfortunately, as per today, it is impossible to translate the commit position gap to the number of events.
+Keep in mind that due to the limitation of KurrentDB, the gap event count is not accurate when subscribing to `$all` stream. It's because the `$all` stream position is the commit position of the event in the global log, not the position of the event in the stream. Unfortunately, as per today, it is impossible to translate the commit position gap to the number of events.
 
 Here is an example of the subscription gap metric exported to Prometheus:
 
diff --git a/docs/src/content/docs/whats-new.mdx b/docs/src/content/docs/whats-new.mdx
index 018436062..c792f403e 100644
--- a/docs/src/content/docs/whats-new.mdx
+++ b/docs/src/content/docs/whats-new.mdx
@@ -1,143 +1,206 @@
 ---
-title: "What's new in 0.15"
+title: "What's new in 0.16"
 sidebar:
-  order: 2
+  order: 1
 ---
 
-# What's new in 0.15
-
-Eventuous v0.15 includes a number of changes and bug fixes, where some of the previous version public APIs are deprecated. Where possible, we made those APIs obsolete and embedded polyfills to make them work, but some APIs are gone for good as it wasn't possible to translate the old API to the new one. Those changes are listed below.
+Eventuous v0.16 is a major release with new infrastructure support, source generators, performance improvements, and important bug fixes. Some breaking changes require attention when upgrading from 0.15.x.
 
 ## Breaking changes
 
 ### .NET SDK targets
 
-Eventuous 0.15 adds support for .NET 8 and removes support for .NET 7. Currently supported SDKs are .NET 6 and .NET 8.
+Eventuous 0.16 drops support for .NET 6 and .NET 7. The library now targets **.NET 8**, **.NET 9**, and **.NET 10**.
 
-### Packages
+### KurrentDB migration
 
-* `Eventuous.AspNetCore` is renamed to `Eventuous.Extensions.DependencyInjection`.
-* `Eventuous.AspNetCore.Web` is renamed to `Eventuous.Extensions.AspNetCore`.
+EventStoreDB packages have been renamed to KurrentDB, reflecting the [product rebrand](https://kurrent.io).
 
-### Domain abstractions
+| Before (0.15) | After (0.16) |
+|---|---|
+| Package `Eventuous.EventStore` | `Eventuous.KurrentDB` |
+| Namespace `Eventuous.EventStore` | `Eventuous.KurrentDB` |
+| Class `EsdbEventStore` | `KurrentDBEventStore` |
+| `AddEventStoreClient(...)` | `AddKurrentDBClient(...)` |
+| `EventStoreClient` | `KurrentDBClient` |
+| `EventStoreClientSettings` | `KurrentDBClientSettings` |
 
-* Aggregate base type without state is removed. The only remaining abstraction is `Aggregate<TState>`. Removal of non-generic `Aggregate` base class triggered a chain of changes for command services and registrations.
-* Aggregate factory extensions require specifying `TState` now. So, use `AddAggregate<T, TState>` instead of `AddAggregate<T>`.
+The old class name `EsdbEventStore` is available as an obsolete type alias for a transitional period. Package references and `using` statements must be updated.
 
-### Persistence
+### StreamEvent property rename
 
-* Aggregate store is no longer used by command services. Its interface, implementation, and registration extensions are marked obsolete. You can still use it outside command services but the whole thing might be removed in the future.
-* `IEventStore` got extensions to work with aggregates, which allowed to avoid using `IAggregateStore`.
-* `IEventWriter.AppendEvents` now needs a collection of `NewStreamEvents` instead of `StreamEvent` as the `StreamEvent` struct has properties that are irrelevant for new events (position, content type, etc).
+`StreamEvent.Position` has been renamed to `StreamEvent.Revision` for clarity. Update all code that accesses this property:
 
-### Command services
+```csharp
+// Before
+var position = streamEvent.Position;
 
-* Non-generic `ICommandService` interface is removed.
-* `IStateCommandService<TState>` is replaced by `ICommandService<TState>`. Both aggregate-based and functional command services implement that interface.
-* Command services no longer use `IAggregateStore`, so it doesn't need to be registered in the DI container. Replace `AddAggregateStore` by `AddEventStore`.
-* Non-generic `Result`, `OkResult` and `ErrorResult` types are removed. Only generic `Result<TState>` is supported. Read more [here](../application/app-service#result).
-* Service registration extension replaced by `AddCommandService<TService, TState>`:
-    * `AddCommandService<TService, TAggregate>`
-    * `AddCommandService<TService, TAggtegate, TId>`
-    * `AddFunctionalService<TState>`
-* Command service metrics are renamed to:
-    * `eventuous_service_duration` for command duration
-    * `eventuous_service_error_count` for command errors
+// After
+var revision = streamEvent.Revision;
+```
 
-### HTTP API extensions
+### Tracing metadata field names
 
-* Controller base class requires `TState` generic argument instead of `TAggregate`, so the new definition is `CommandHttpApiBase<TState>`. Therefore, it can be used with both aggregate-based and functional command services. It takes `ICommandService<TState>` as a dependency.
-* `CommandHttpApiBaseFunc` base class is removed because it's no longer required. Use `CommandHttpApiBase<TState>` instead.
-* Controller methods need to return `ActionResult<Result<TState>.Ok>`.
-* `MessageMap` optional dependency for controllers is replaced by `CommandMap<HttpContext>`, so it's now possible to populate additional command properties from the HTTP context.
-* `AggregateCommands<TAggregate>` attribute is gone, use `HttpCommands<TState>` instead. It supports both aggregate-based and functional services.
-* `HttpCommand<TAggregate>` attribute is gone, use `HttpCommand<TState>` instead. It supports both aggregate-based and functional services.
-* `MapAggregateCommands<TAggregate>` is replaced with `MapCommands<TState>`.
-* `MapDiscoveredCommands<TAggregate>` is replaced with `MapDiscoveredCommands<TState>`.
-* `MapCommand<TAggregate, TCommand>` is replaced by `MapCommand<TState, TCommand>`.
-* `MapCommand<TAggregate, TCommand, TResult>` is gone as custom results aren't supported in command mapping. Use `MapCommand<TState, TCommand>` and `Result<TState>` instead.
-* The same applies to command mappings with external-internal command conversion. Aggregate constraint is replaced by state type constraint, and a custom result type is no longer supported in favour of `Result<TState>`.
+Metadata field names used for distributed tracing have changed, and the parent span id has been removed:
 
-:::note
-Current APIs for working with HTTP is [documented here](../application/command-api).
-:::
+| Before | After |
+|---|---|
+| `trace-id` | `$traceId` |
+| `span-id` | `$spanId` |
+| `parent-span-id` | _(removed)_ |
 
-### Subscriptions
+The `TracingMeta` record no longer has the `ParentSpanId` property. If you read tracing metadata from event metadata directly, update the field names. If you only use the Eventuous diagnostics API, no changes are needed beyond recompilation.
 
-Subscriptions are now being registered in the DI container using keyed dependencies. It requires to use `Microsoft.Extensions.DependencyInjection` version 8 and higher. If you use ASP.NET Core DI container in combination with another container like Autofac, make sure you use the version that supports keyed registrations in ASP.NET Core services collection.
+### Spyglass API
 
-Subscriptions also got `IEventSerializer` (all of them) and `IMetadataSerializer` (EventStoreDB, Postgres and SQL Server) as dependencies, and subscription option properties holding those are removed. The reason is that serializers can now play nicely with dependency injection, which is particularly relevant to event serializers as they depend on `TypeMapper`. It is now easier to use separated type maps. One case for that is Eventuous tests where the global type map created issues with conflicting type registrations.
+Spyglass now uses source-generated module initializers to populate its registry automatically. The `AddEventuousSpyglass()` DI registration call is now a no-op (marked obsolete). The ping endpoint (`/spyglass/ping`) now returns `"v1.0"`. Previous versions of the Spyglass UI are not compatible with this version of the API.
 
-### Producers
+## New features
 
-* `IEventProducer` was already marked obsolete, and it's now gone. the `IProducer` interface is 100% compatible, so you can need to rename the usages.
-* Producers without options are no longer supported.
+### SQLite event store
 
-### Postgres
+A new `Eventuous.Sqlite` package provides a full SQLite-based event store for embedded and local applications (desktop, mobile, CLI tools) that need event sourcing without external database dependencies.
 
-* Postgres store options now include connection string, schema name and initialize properties.
-* Postgres store now uses `NpgsqlDataSource`.
-* Calling `AddEventuousPostgres` registers `NpgsqlDataSource` in the container using the provided options.
-* Loading `PostgresStoreOptions` from the configuration is now supported.
-* Postgres subscriptions use `NpgsqlDataSource` as well, but registering a subscription doesn't add the data source as subscription options don't have the connection string. You can either register the data source manually using `Npgsql` own extensions, or use `AddEventuousPostgres`.
+It includes an event store, subscriptions (all-stream and per-stream), checkpoint store, projector base class, and automatic schema initialization. WAL mode is enabled by default.
 
-### SQL Server
+```csharp
+builder.Services.AddEventuousSqlite(
+    "Data Source=myapp.db",
+    schema: "eventuous",
+    initializeDatabase: true
+);
+builder.Services.AddEventStore<SqliteStore>();
+```
 
-* SQL Server store options now include connection string, schema name and initialize properties.
-* Calling `AddEventuousSqlServer` registers the connection factory, which then is used by the store.
-* SQL Server subscription options class also has the connection string property, so if your service only implements subscriptions, you don't need to call `AddEventuousSqlServer`. However, subscriptions don't initialize the schema.
+See the [SQLite infrastructure documentation](../infra/sqlite) for full details.
 
-## New things
+### Azure Service Bus
 
-There are many small improvements in 0.15, here you can find the list of most important improvements.
+A new `Eventuous.Azure.ServiceBus` package adds [Azure Service Bus](https://learn.microsoft.com/en-us/azure/service-bus-messaging/) as a producer and subscription target.
 
-### Services
+**Producer** publishes messages to queues or topics:
 
-As it becomes clear from breaking changes, Eventuous doesn't distinct aggregate-based and functional services when services are being used in public APIs. Both service flavours now implement a single interface `ICommandService<TState>`, which greatly simplified all downstream APIs like command-handling controllers and minimal API command handlers. You can now decide to move from one flavour to another and only reimplement the service itself without changing the rest of the application.
+```csharp
+builder.Services.AddSingleton(new ServiceBusClient(connectionString));
+builder.Services.AddProducer<ServiceBusProducer, ServiceBusProducerOptions>(
+    options => options.QueueOrTopicName = "my-topic"
+);
+```
 
-Command services how can resolve the store based on command payload. It can be useful, for example, in multitenant environments where the command contains information about the tenant, so you can resolve a different store for each tenant for data isolation.
+**Subscription** consumes messages from queues or topics, with support for **session-based processing**:
 
-### Gateways
+```csharp
+builder.Services.AddSubscription<ServiceBusSubscription, ServiceBusSubscriptionOptions>(
+    "PaymentsIntegration",
+    b => b
+        .Configure(cfg => cfg.QueueOrTopic = new Topic("payments"))
+        .AddEventHandler<PaymentsHandler>()
+);
+```
+
+For session-ordered message processing, configure `SessionProcessorOptions` on the subscription options.
+
+### Source generators
+
+Eventuous 0.16 includes three new compile-time source generators that eliminate runtime reflection and improve AOT compatibility.
 
-Using keyed dependencies for registering subscription allows using the same event handler for multiple subscriptions. It is also supported in gateways. Previously, multiple gateways would reuse the same transformation function or class, even if you explicitly provide different implementations for different gateways. Not every gateway registration is able to distinct transformations between them, so use one of those:
+#### Type mapping generator
+
+The `[EventType]` attribute is now processed at compile time. A module initializer is generated that automatically registers all decorated event types in the `TypeMap`:
 
 ```csharp
-AddGateway<TSubscription, TSubscriptionOptions, TProducer, TProduceOptions, TTransform>()
+[EventType("BookingImported")]
+public record BookingImported(string RoomId, LocalDate CheckIn, LocalDate CheckOut, decimal Price);
 ```
 
+No manual `TypeMap.RegisterKnownEventTypes()` call is needed when using the source generator. The generated code runs at module initialization before any application code.
+
+#### Consume context converter generator
+
+Event handlers that use `IMessageConsumeContext<T>` previously relied on runtime-compiled expressions for type conversion. A source generator now produces these converters at compile time, eliminating reflection overhead.
+
+#### Event usage analyzer
+
+A new diagnostic analyzer (`EVTC001`) warns at compile time when event types used in `Apply<TEvent>()`, `When<TEvent>()`, or `On<TEvent>()` handler registrations are missing the `[EventType]` attribute. This catches missing type map registrations before runtime. If the type is registered explicitly (not via attribute), the warning is suppressed.
+
+#### HTTP command analyzer
+
+A new analyzer detects route mismatches and state type mismatches in HTTP command mappings. A companion generator can map HTTP commands and emits warnings on duplicate routes.
+
+### Checkpoint initial position
+
+Subscriptions with checkpoints now support configuring the **initial position** when no checkpoint exists. Previously, subscriptions always started from the beginning. You can now choose:
+
 ```csharp
-AddGateway<TSubscription, TSubscriptionOptions, TProducer, TProduceOptions>(
-    string                             subscriptionId,
-    RouteAndTransform<TProduceOptions> routeAndTransform
-)
+builder.Services.AddSubscription<MySubscription, MySubscriptionOptions>(
+    "MySubscription",
+    b => b
+        .Configure(cfg => cfg.StartFrom = InitialPosition.Latest)
+        .AddEventHandler<MyHandler>()
+);
 ```
 
-### Relational databases
+- `InitialPosition.Earliest` (default) — start from the beginning of the stream
+- `InitialPosition.Latest` — start from the current end of the stream, only processing new events
 
-Both Postgres and SQL Server libraries now use the same base implementation. It's now possible to add support for other relational databases using the same abstraction, if someone is willing to experiment or contribute.
+### Gap handling for PostgreSQL global subscriptions
 
-Both Postgres and SQL Server libraries got simple projector implementations as well as checkpoint stores.
+PostgreSQL global subscriptions now detect and handle gaps in event sequences. When a gap is detected (due to uncommitted transactions or deleted events), the subscription can insert tombstone events to bridge the gap and continue processing. This prevents subscriptions from stalling on missing sequence numbers.
 
-TODO: Add docs links
+### Performance optimizations
 
-Postgres library supports Postgres 7+ with the latest version of `Npgsql` and uses `NpgsqlDataSource`.
+Several internal optimizations reduce memory allocations in the subscription pipeline:
 
-All RDBMS-based subscriptions use frequent polling with backpressure. It means that when the polling query doesn't return new events, the subscription will start increasing the polling interval. It allows decreasing the number of empty queries to the database when the system is not under load.
+- **HandlingResults**: uses a single-field optimization for the common single-handler case, avoiding list allocation (158x faster for single results)
+- **ContextItems**: lazy-initialized backing dictionary, saving 104 bytes per message when no context items are used
+- **Manual iteration**: replaced LINQ operations with array indexing in hot paths to avoid allocator pressure
 
-Check the relevant RDBMS-based implementation documentation for more details.
+### Google PubSub automatic reconnection
 
-Subscriptions now provide lag metrics and health checks.
+Google PubSub subscriptions now automatically detect unrecoverable subscriber failures and trigger reconnection, matching the behavior of other subscription implementations.
+
+### Custom serializer for subscriptions
+
+All subscriptions now accept an optional `IEventSerializer` parameter, allowing you to use a different serializer per subscription instead of the global default.
+
+### MongoDB custom collection names
+
+MongoDB projections and checkpoint store now support custom collection names via `MongoProjectionOptions<T>`:
+
+```csharp
+builder.Services.AddSubscription<..., ...>(
+    "MyProjection",
+    b => b
+        .AddEventHandler(sp => new MyProjector(sp, "custom_collection_name"))
+);
+```
 
-Subscriptions now handle transient errors and support retries. Each RDBMS-based implementation has its own logic for that.
+The default collection name is derived from the document type with automatic suffix removal (`Document`, `Entity`, `View`, `Projection`).
 
-### MongoDB
+### Command service improvements
 
-MongoDB projections now support bulk operations.
+- **Override events and expected version**: command services now support amending the proposed append before persistence, allowing you to modify events or override the expected version. This is useful for advanced scenarios like multitenant event routing.
+- **Functional service bug fix**: fixed a bug where `ProposedEvent` was passed to `State.When()` instead of the raw event data, preventing correct state updates when using `ICommandService<TState>`.
+- **Store resolution by command**: command services can resolve the store based on command payload, useful for multitenant environments.
 
-### Redis
+## Bug fixes
 
-Experimental support for Redis event store and subscriptions added as a separate package.
+- **RabbitMQ queue binding** (#498): fixed `QueueBind` using `SubscriptionId` instead of the resolved queue name when `QueueOptions.Queue` was overridden. Also fixed `Gateway.GetOriginalStream()` returning null due to incorrect type casting.
+- **Aggregate version calculation** (#475): fixed version tracking for deleted streams by storing `OriginalVersion` as a field instead of computing it.
+- **PostgreSQL read_stream_backwards** (#464): fixed guard clause that incorrectly mixed page size with position validation, causing valid backwards reads to return empty results.
+- **AddCompositionEventHandler DI registration** (#462): fixed factory function registration — the factory was being registered as a value instead of being invoked during resolution.
+- **Service Bus message attributes** (#460): non-serializable custom attributes are now filtered out before sending to Azure Service Bus, preventing serialization errors.
+- **Type map analyzer** (#458): suppresses warnings when types are registered explicitly rather than via the `[EventType]` attribute.
+- **SQL Server improvements** (#431): multiple stored procedure improvements, fixes for issue #428 (optimistic concurrency reporting).
+- **SQL Server WrongExpectedVersion** (#376): stored procedures now properly report optimistic concurrency exceptions.
+- **ActionResult creation** (#378): fixed incorrect `ActionResult` construction in HTTP command API.
+- **Stream not found log** (#403): stores no longer log a warning when reading a non-existent stream if the caller expects it (e.g., when using `ExpectedVersion.Any`).
+- **Global position in FromSuccess** (#386): corrected position type used in success result.
+- **Connection string from options** (#417): PostgreSQL connection string is now properly fetched from connection options.
 
-### Testing
+## Infrastructure updates
 
-A simple testing library `Eventuous.Testing` now allows creating test specs for aggregates. Eventuous uses it internally in tests.
+- KurrentDB client updated to 1.3.0
+- MongoDB driver updated
+- .NET 10 GA support (previously preview)
+- TUnit test framework upgraded
diff --git a/docs/src/content/versions/0.15.json b/docs/src/content/versions/0.15.json
new file mode 100644
index 000000000..0a767b2fb
--- /dev/null
+++ b/docs/src/content/versions/0.15.json
@@ -0,0 +1,96 @@
+{
+  "sidebar": [
+    {
+      "label": "Introduction",
+      "slug": "intro"
+    },
+    {
+      "label": "What's New",
+      "slug": "whats-new"
+    },
+    {
+      "label": "Concepts",
+      "collapsed": true,
+      "items": [
+        {
+          "label": "Prologue",
+          "autogenerate": {
+            "directory": "prologue"
+          }
+        },
+        {
+          "label": "Domain",
+          "autogenerate": {
+            "directory": "domain"
+          }
+        },
+        {
+          "label": "Persistence",
+          "autogenerate": {
+            "directory": "persistence"
+          }
+        }
+      ]
+    },
+    {
+      "label": "Building Apps",
+      "collapsed": true,
+      "items": [
+        {
+          "label": "Application",
+          "autogenerate": {
+            "directory": "application"
+          }
+        },
+        {
+          "label": "Subscriptions",
+          "autogenerate": {
+            "directory": "subscriptions"
+          }
+        },
+        {
+          "label": "Read Models",
+          "autogenerate": {
+            "directory": "read-models"
+          }
+        },
+        {
+          "label": "Producers",
+          "autogenerate": {
+            "directory": "producers"
+          }
+        },
+        {
+          "label": "Gateway",
+          "autogenerate": {
+            "directory": "gateway"
+          }
+        }
+      ]
+    },
+    {
+      "label": "Operations",
+      "collapsed": true,
+      "items": [
+        {
+          "label": "Diagnostics",
+          "autogenerate": {
+            "directory": "diagnostics"
+          }
+        },
+        {
+          "label": "Infrastructure",
+          "autogenerate": {
+            "directory": "infra"
+          }
+        },
+        {
+          "label": "FAQ",
+          "autogenerate": {
+            "directory": "faq"
+          }
+        }
+      ]
+    }
+  ]
+}
diff --git a/docs/tsconfig.json b/docs/tsconfig.json
index bcbf8b509..2c2a6f54e 100644
--- a/docs/tsconfig.json
+++ b/docs/tsconfig.json
@@ -1,3 +1,9 @@
 {
-  "extends": "astro/tsconfigs/strict"
+  "extends": "astro/tsconfigs/strict",
+  "compilerOptions": {
+    "baseUrl": ".",
+    "paths": {
+      "@components/*": ["src/components/*"]
+    }
+  }
 }