What is Flowcore?

Flowcore is an event-first data platform for building systems that need durable history, real-time processing, and the ability to reconstruct state.

Instead of storing only the latest version of a record, your application records the facts that produced that state. An order was placed. A payment was authorized. A sensor crossed a threshold. Flowcore stores those facts as immutable events and makes them available to the systems that need to react to them.

This page gives you the big picture before you start working with Flowcore resources, APIs, or Data Pathways.

The problem Flowcore solves

Most applications begin with a database that stores current state. That works well until teams need to answer questions such as:

• What exactly happened before this record reached its current state?
• Can we rebuild a database, search index, or analytics model after it becomes corrupted?
• Can a new service process events that were produced before the service existed?
• Can we reproduce a production incident from the original sequence of facts?
• Can operational systems, analytics, automation, and AI workflows use the same history?

A conventional mutable database often cannot answer these questions by itself. Updates overwrite previous values, audit tables vary between services, and point-to-point integrations create separate copies of the same history.

Flowcore gives that history a durable home. Applications append events to Flowcore, and consumers use those events to build the state or behavior they need.

A simple mental model

Think of Flowcore as a durable timeline between the systems that produce facts and the systems that use them.

1. An application or integration publishes an event.
2. Flowcore stores the event before downstream processing begins.
3. Data Pathways select relevant events and deliver them to consumers.
4. Consumers update read models, call APIs, write files, trigger automation, or perform other work.
5. If a consumer changes or fails, retained events can be replayed from an earlier position.

The stored event is the durable fact. A PostgreSQL table, search index, cache, warehouse table, or vector index built from those facts is a projection. Projections are designed for a particular use case and can be rebuilt when necessary.

What Flowcore provides

Flowcore combines several capabilities that are usually assembled from separate products:

Durable event storage

Events are retained as immutable records with identity, routing information, metadata, and time information. The event history supports auditing, debugging, recovery, and replay.

Organized event contracts

Events are organized under tenants, data cores, flow types, and event types. This hierarchy gives teams stable names for ownership, permissions, subscriptions, and lifecycle management.

Ingestion and querying

Applications can publish through Pathways, the TypeScript SDK, or ingestion APIs. Authorized clients can query retained events, move through time buckets, and resume from known positions.

Reliable event delivery

Data Pathways continuously deliver matching events to application endpoints. They track progress, retry failed delivery, expose operational state, and can replay historical data.

Replaceable read models

Consumers can project events into relational databases, document stores, search engines, graphs, files, warehouses, caches, or AI-oriented stores. Each model can be optimized independently without changing the original event history.

Governance and operations

Tenant-scoped identity, access controls, API keys, policies, variables, secrets, delete protection, quotas, and operational signals help teams run event workloads safely.

Where Flowcore fits in your architecture

Flowcore does not replace every database or API. It becomes the durable event backbone around which those systems operate.

A typical application still uses a database for fast user-facing queries. The difference is that the database can be treated as a projection of retained facts rather than the only record of what happened.

For example, an order service might:

1. Validate a PlaceOrder command.
2. Publish an order.placed.0 event.
3. Project the event into a database used by the order UI.
4. Deliver the same event to payment, fulfillment, analytics, and notification consumers.
5. Later replay order history into a new fraud-detection model.

The producer does not need to coordinate every downstream system. Each consumer can evolve at its own pace while using the same durable history.

When Flowcore is a good fit

Flowcore is especially useful when your system needs one or more of the following:

• An audit-quality history of business or operational changes
• Reliable asynchronous integration between services
• Recovery by replaying historical events
• Multiple read models built from the same facts
• Real-time operational, analytics, or automation workflows
• Event-sourced services or CQRS architectures
• A governed event layer across teams or products
• Historical data for model training, evaluation, or AI context

A simple application that only needs basic CRUD and has no replay, audit, or integration requirements may not need an event platform. Flowcore adds the most value when history and downstream processing are part of the system's design, not an afterthought.

Flowcore v2 at a glance

Flowcore v2 is the current platform direction. New integrations should use:

• REST-backed platform services and @flowcore/sdk
• @flowcore/pathways for typed event contracts, publishing, and handlers
• Managed or virtual Data Pathways for delivery and replay
• IAM roles, policies, bindings, and API keys for access control

Older Flowcore material may refer to GraphQL administration, scenarios, strands, adapters, or hosted transformer shells. Those are legacy concepts and should not be used as the starting point for a new v2 implementation.

What to read next

Continue with Core concepts and the event data model to understand the resource hierarchy and event envelope.

Then read How events move through Flowcore for the end-to-end path from publishing to delivery, projection, and replay.