Showcases¶
Seven open-source applications built on clink, each in a real domain and each complete: data goes in, decisions and tables come out, and a checker that never touches clink says whether every output is right. They use clink the way its users would, as an installed release, a runtime image or a build of its binaries, and run whatever else they need in Docker, on one machine.
Start with the one closest to your problem.
| Showcase | The application | clink runs | Written in |
|---|---|---|---|
| market-pulse | Market data: price bars, spreads, patterns and a mistyped print | in one process, from Python and on a cluster | SQL, C++, Python |
| card-sentry | Card fraud detection, with alerts and decisions delivered exactly once | in one process and on a cluster | C++ |
| grounded | Retrieval for an operations assistant | in one process | SQL |
| transfer-sentry | Fraud detection on a transaction graph in Neo4j | on a cluster | SQL |
| half-time | A delivery platform on the night of a final | on a cluster with a standby Coordinator | SQL, C++ |
| coldchain | Refrigerated freight monitoring | in one process and on a cluster | C++ |
| playhead | Video playback analytics | on Kubernetes, through the operator | SQL |
Find one by what you want to see¶
| To see | Look at |
|---|---|
| clink in one process, with no cluster | market-pulse, grounded, coldchain, card-sentry |
| clink from Python | market-pulse |
| The typed C++ API | coldchain, card-sentry, the operator in market-pulse, the riders job in half-time |
| Many SQL jobs feeding each other | half-time, transfer-sentry, playhead |
| Event-pattern detection | card-sentry in C++; market-pulse and half-time with MATCH_RECOGNIZE |
| Exactly-once delivery through a Worker kill | card-sentry, transfer-sentry, half-time, playhead |
| A Coordinator failover | half-time, playhead |
| A job upgraded through a savepoint | half-time, playhead |
| A running job rescaled | half-time |
| Kubernetes and the operator | playhead |
| A job scaled to zero and woken by new data | playhead |
| Change data capture | half-time, from PostgreSQL and MySQL |
| Neo4j as a sink and a lookup | transfer-sentry, half-time |
| Cloud storage and table formats | playhead with Iceberg, GCS and Azure; half-time with Parquet and Delta |
| SQL-native AI | grounded |
| Live state served over HTTP | card-sentry |
| A stopped job's state read as data | market-pulse |
| Incidents replayed byte for byte | market-pulse, card-sentry, grounded, half-time |
| A run checked against the exactly-once specification | card-sentry, half-time |
| Traces, metrics and lineage | playhead |
| What a run costs in CPU and memory | half-time, playhead |
How every showcase is checked¶
They share one discipline, which is what makes their results worth reading.
- A deterministic tape. A generator writes the input from a seed, so every run sees the same events, out of event-time order the way real feeds are.
- Planted cases and negative controls. The tape carries incidents that must be found and near-misses that must not be, at known coordinates.
- An independent checker. It never reads the application's code or clink's state. It works out from the tape alone what each output must hold, reads every store back through a client of its own, and fails the run on a row too many or too few.
- Failure on purpose. Most showcases kill a Worker mid-stream, and some fail over a Coordinator, upgrade a job or resend a batch a producer had already delivered. The checks must pass anyway: a store declared exactly once must hold nothing twice, and a store declared at least once is checked with its copies counted.
- Every release candidate, before the tag. Six of the seven run their
checks in CI on every push, against the clink they pin. Before a clink
release is tagged, the same CI runs against the release candidate
(
scripts/check-showcases.sh): the SDK and runtime image the release would publish, or the candidate's source where a showcase needs a connector the SDK leaves out. half-time, whose seventeen services outgrow a hosted runner, runs on one machine against the candidate and leaves a bundle of evidence: which clink and which half-time ran, what each fault scene did, and every check's verdict. The release check accepts it only for exactly that candidate, with every scene run and every check passing, and reports all seven passed only then. A showcase that fails holds the release until the cause is fixed, in clink or in the showcase.
Each showcase's page follows the same order: what the application does, where clink does the work, what a run proves, what is distinctive, and how to run it.