Reset projection without downtime

[jlabedo]

Description
During the projection reset you see stale data on your queries. As you accumulate more and more events in your stream, the reset takes longer and has an impact on the end user.
The feature would be to have a reset without downtime (or very low).

Example
while resetting, a new table could be built while the reset is ongoing, the old table would continue to be updated by events. When the reset is complete, delete old table and rename the new one.

[dgafka]

New table would mean queries needs to be changed and projection initialization would need to be aware that it should create for the rebuild.
The current rebuild method is not ideal, is just solution provided out of the box by Prooph abstraction.
I personally think there should be no rebuild method at all, and only register/unregister projection in given version.

What I mean by that is enabling blue/green projection deployment.
To make it work, we would need to allow registering given projection in specific version.
Version would be passed to projection initialize and projection handlers via metadata. This way they would know, how to produce tables and where to project.

After projection is built in new version, developer can verify if all is fine and if so do the switch to read from new tables. Old projection can then be unregistered.
The only caveat is, that we would need to keep information of registered projection versions so we know that we call the projection for each of the available version. This can be done in the code tho.

#[Projection("balance")]
#[ProjectionVersions([1, 2])]
class BalanceProjection

[jlabedo]

Sounds nice !

So the developer would deploy:
deployment 1

#[Projection("balance")]
#[ProjectionVersions([1, 2])]
class BalanceProjection {
    #[EventHandler()]
    public function whenSomethingHappened(SomethingHappened $event, array $metadata): void
    {
        // this is executed for all versions, and $metadata['ecotone.projection.version'] would be the currently running projection version
        if ($metadata['ecotone.projection.version'] === 1) {
           // insert into `first_table`
        } else {
           // insert into `a_new_table`
        }
    }

    #[EventHandler(), ProjectionVersion(2)]
    public function whenSomethingNewHappened(SomethingNewHappened $event): void
    {
        // this is executed only for version 2
    }

    #[ProjectionInitialization, ProjectionVersion(1)]
    public function initialization(): void
    {
        $this->connection->executeStatement("CREATE TABLE first_table (id UUID NOT NULL)";
    }

    #[ProjectionInitialization, ProjectionVersion(2)]
    public function initialization(): void
    {
        $this->connection->executeStatement("CREATE TABLE a_new_table (id NOT NULL, a_new_column VARCHAR)";
    }

Two projections are running at the same time. (We would have to do something to avoid that the first event hitting the new projection is blocking the flow in case of synchronous projections. Maybe have one synchronous projection and the other being a polling projection ?)

deployment 2
When both projections are fully loaded, we change our queries to use a_new_table

deployment 3
We get rid of the first projection version

#[Projection("balance")]
class BalanceProjection {
    #[EventHandler()]
    public function whenSomethingHappened(SomethingHappened $event, array $metadata): void
    {
    }

    #[EventHandler()]
    public function whenSomethingNewHappened(SomethingNewHappened $event): void
    {
    }

    #[ProjectionInitialization]
    public function initialization(): void
    {
        $this->connection->executeStatement("CREATE TABLE a_new_table (id NOT NULL, a_new_column VARCHAR)";
    }

Did I understood correctly ?

[dgafka]

Ye, the flow is the same I had in mind, but implementation is a bit different.
In general projection version becomes first class citizen, you may use it, but you don't have too.

deployment 1

#[Projection("balance")]
// I am not sure about this way of defining it.
#[ProjectionVersions([1, 2])]
class BalanceProjection {
    #[EventHandler()]
    public function whenSomethingHappened(SomethingHappened $event, #[ProjectionVersion] $version): void
    {
        // this is executed for all versions, and $metadata['ecotone.projection.version'] would be the currently running projection version
        
        // The process will be the same in most of the cases, so can be simplified. That would result in `customers_v1` for example
        $this->connection->insert($version->addSuffix("customers"), ["id" => $event->id])
    }

    #[ProjectionInitialization]
    public function initialization(#[ProjectionVersion] $version): void
    {
        $tableName = $version->addSuffix('customers');
        $this->connection->executeStatement("CREATE TABLE {$tableName} (id UUID NOT NULL)";
    }

deployment 3

The version stays, as we generate and insert into tables accordingly.

#[Projection("balance")]
#[ProjectionVersions([2])]
class BalanceProjection {

    #[EventHandler()]
    public function whenSomethingHappened(SomethingHappened $event, #[ProjectionVersion] $version): void
    {
          $this->connection->insert($version->addSuffix("customers"), ["id" => $event->id])
    }

    #[ProjectionInitialization]
    public function initialization(#[ProjectionVersion] $version): void
    {
        $tableName = $version->addSuffix('customers');
        $this->connection->executeStatement("CREATE TABLE {$tableName} (id UUID NOT NULL)";
    }

[dgafka]

In general code looks the same when we don't use the versioning, yet if we want we "upgrade" it and we can now have blue/green deployment with projections.

[dgafka]

And I think that's more an discussion ticket than issue, mate :)

[jlabedo]

Here you go ;)

[dgafka]

Two projections are running at the same time. (We would have to do something to avoid that the first event hitting the new projection is blocking the flow in case of synchronous projections. Maybe have one synchronous projection and the other being a polling projection ?)

Ye, that's the challenge. During "catch-up" phase we would need custom configuration, once projection up to date we would switch to a different one.