eventsalsa

eventsalsa

A component-based stack for event sourcing in Go

Open documentation View GitHub

Components

Build around the pieces you need today and grow into the rest when the system demands it.

database

eventsalsa/store

Append-only event storage with optimistic concurrency and a transaction-first API.

  • PostgreSQL-backed
  • Append-only
  • Optimistic concurrency
Read more →
hub

eventsalsa/projector

Run async projections across one or more daemon instances, with PostgreSQL-backed rebalancing.

  • PostgreSQL-native
  • Distributed daemon
  • Dynamic filtering
Read more →
lock

eventsalsa/encryption

Standalone envelope encryption for PII and secrets, with crypto-shredding and HMAC hashing for sensitive lookups.

Read more →

Why eventsalsa?

Keep the architecture explicit, the runtime PostgreSQL-native, and the domain model free of framework ownership.

extension

Component-based

Use only the modules you need. The store, projector, and encryption packages can be adopted independently.

account_tree

No infrastructure creep

eventsalsa does not require aggregate root base types or framework-owned structs in your domain model.

sync_alt

Optimistic concurrency

Expected versions make concurrent writes explicit and keep aggregate updates honest.

database

PostgreSQL-driven

The store and projector are built on PostgreSQL - no need for a 3rd party message broker.

schema

Domain-Driven Design

Versioned events support rich domain modelling while keeping the model explicit and free from framework-owned types.

view_quilt

Clean architecture

Keep event infrastructure at the edges while the application model remains plain Go.

eventsalsa/store

eventsalsa/store gives you an append-only event log, optimistic concurrency, and a transaction-first API without prescribing your domain model.

Install terminal
go get github.com/eventsalsa/store
  • check Append and read event streams in a PostgreSQL-backed event store.
  • check Use optimistic concurrency through explicit expected versions.
  • check Control transaction boundaries yourself with the pgx.Tx you already have.
main.go 
import (  "time"  "github.com/eventsalsa/store"  "github.com/eventsalsa/store/postgres"  "github.com/google/uuid")s := postgres.NewStore(postgres.DefaultStoreConfig())event := store.Event{  StreamType: "User",  StreamID: userID,  EventID: uuid.New(),  EventType: "UserRegistered",  EventVersion: 1,  Payload: payload,  Metadata: []byte(`{}`),  CreatedAt: time.Now(),}if _, err := s.Append(ctx, tx, store.NoStream(), []store.Event{event}); err != nil {  return err}
main.go 
type AccountProjection struct{}func (p *AccountProjection) Name() string {  return "account_projection"}func (p *AccountProjection) Handle(ctx context.Context, tx pgx.Tx, event store.PersistedEvent) error {  return nil}daemon := projector.New(  db,  eventStore,  []projector.Projection{    projector.FilterStreamTypes(&AccountProjection{}, "Account"),  },  projector.WithBatchSize(100),  projector.WithPollInterval(500 * time.Millisecond),)if err := daemon.Start(ctx); err != nil {  return err}

eventsalsa/projector

eventsalsa/projector runs async projections across one or more daemon instances, with PostgreSQL-backed assignment and rebalancing.

Install terminal
go get github.com/eventsalsa/projector
  • check Start with one daemon instance and add more when you want projection assignments distributed.
  • check Keep coordination in PostgreSQL while the leader rebalances projections across live instances.
  • check Filter stream types with projector.FilterStreamTypes without requiring a separate broker.