Every event.
A clearer picture.

Event sourcing & CQRS for Go.
Keep the history. Rebuild the state. Give your application a memory you can work with.

Start building View source

go get go-mink.dev

Go 1.26+ · Apache 2.0

01—04 FROM HISTORY TO STATE

event explorerINTERACTIVE DEMO

orders / order-0424 events

≡ READ MODEL

Order summary#042

Customer: Ada
Items: 2
Total: €58.00

Shipped

rebuilt from 4 / 4 events

Same events. Same state. Every replay.

Go back in time. Select an event or hit replay.

A toolkit that fits your stack

Idiomatic Go

PostgreSQL

CQRS

Open interfaces

Apache 2.0

01 / A DIFFERENT WAY TO THINK ABOUT STATE

Keep the story.
Build any view.

A row tells you what is true now. An event stream tells you how you got here. go-mink gives you the building blocks to use both.

Express an intention

Commands capture what should happen. Your domain decides whether it can.

Commands & aggregates

Record what happened

Append a fact to the stream. Version checks help protect against conflicting writes.

Streams & concurrency

Project what you need

Turn the same events into useful views. Replay history when your questions change.

Read models & projections

02 / THE DEVELOPER EXPERIENCE

Your domain.
Plain Go.

Start with an event and a stream. Add the patterns your application needs, when it needs them.

Interfaces you can implement
Errors you can handle
Context you can carry through

Start building

append.goGO

func appendOrder(ctx context.Context, store *mink.EventStore) error {
    // Register concrete types for typed replay.
    store.RegisterEvents(OrderCreated{}, ItemAdded{})

    events := []any{
        OrderCreated{CustomerID: "customer-456"},
        ItemAdded{SKU: "GO-01", Quantity: 2},
    }

    // NoStream rejects a second creation of this stream.
    return store.Append(ctx, "order-123", events,
        mink.ExpectVersion(mink.NoStream),
    )
}

Plain Go structs, typed replay, and an explicit version check. Function excerpt; the complete example includes event types and store setup.

View complete example

03 / SMALL PIECES. A COMPLETE TOOLKIT.

Built for the parts
beyond the happy path.

Persistence is just the beginning. Compose the pieces you need for a system that evolves with your domain.

A durable event history

Append to streams with optimistic concurrency. Use PostgreSQL for persistence and memory for fast, isolated tests.

Explore the event store

Views shaped for your queries

Build read models from events. Choose inline, asynchronous, or live projections and wire the execution explicitly.

Understand projections

Workflows across boundaries

Coordinate multi-step processes with sagas. Publish committed events through a transactional outbox on supported adapters.

Connect your services

Data protection by design

Field encryption, key management, and erasure tools help you implement your application’s data policies.

Explore data protection

Confidence at every change

Describe behavior with Given / When / Then tests. Evolve event schemas with upcasters while keeping history readable.

Test your domain

Evaluate it on your workload.Read the benchmark methodology

04 / YOUR NEXT COMMIT STARTS HERE

A path from curious
to shipping.

Browse the documentation

01 / BUILD

Learn by doing.

Build an e-commerce application, from your first event to production concerns.

Follow the tutorial 02 / UNDERSTAND

Get the mental model.

Work through event sourcing, CQRS, middleware, and projections in the article series.

Read the series 03 / EXPLORE

Go a level deeper.

Find the interfaces, patterns, and design decisions behind the toolkit.

Explore the API

BEFORE YOU BUILD

Good questions.
Straight answers.

Event sourcing is a design choice.
Make it an informed one.

Is event sourcing right for my application?+

It is useful when history, traceability, rebuilding views, and complex domain behavior matter. It also adds schema evolution and operational responsibilities. For straightforward CRUD, a conventional database model may be simpler. Read the architecture guide.

Do I need a separate event database?+

No. The PostgreSQL adapter stores events in PostgreSQL. The memory adapter is useful for tests and local experiments; it is not durable storage. Explore adapters.

Do projections run automatically on append?+

No. Appending an event and processing a projection are separate operations. Configure the projection engine and invoke inline processing, run asynchronous workers, or notify live projections according to your application’s needs. Understand projection strategies.

Can I evolve events and protect personal data?+

Upcasters help read older event schemas. Field encryption, erasure, and export capabilities support your data governance design; your retention policy and compliance obligations still need application-specific decisions. Read the security guide.

YOUR NEXT EVENT STARTS HERE

Build something
worth remembering.

Open source. Plain Go. Ready for your domain.

Get started with go-mink Join the discussion

Every event.A clearer picture.

Keep the story.Build any view.