[{"data":1,"prerenderedAt":788},["ShallowReactive",2],{"navigation":3,"\u002Fdocs\u002Freference\u002Fglossary":314,"\u002Fdocs\u002Freference\u002Fglossary-surround":784},[4,38,86,149,176,219,257,273],{"title":5,"path":6,"stem":7,"children":8,"icon":37},"Getting Started","\u002Fdocs\u002Fgetting-started","1.docs\u002F1.getting-started\u002F1.index",[9,12,17,22,27,32],{"title":10,"path":6,"stem":7,"icon":11},"Getting started","i-lucide-flag",{"title":13,"path":14,"stem":15,"icon":16},"Modules overview","\u002Fdocs\u002Fgetting-started\u002Fmodules-overview","1.docs\u002F1.getting-started\u002F2.modules-overview","i-lucide-boxes",{"title":18,"path":19,"stem":20,"icon":21},"Installation","\u002Fdocs\u002Fgetting-started\u002Finstallation","1.docs\u002F1.getting-started\u002F3.installation","i-lucide-download",{"title":23,"path":24,"stem":25,"icon":26},"License configuration","\u002Fdocs\u002Fgetting-started\u002Flicense-configuration","1.docs\u002F1.getting-started\u002F4.license-configuration","i-lucide-key-round",{"title":28,"path":29,"stem":30,"icon":31},"Your first app","\u002Fdocs\u002Fgetting-started\u002Ffirst-app","1.docs\u002F1.getting-started\u002F5.first-app","i-lucide-square-play",{"title":33,"path":34,"stem":35,"icon":36},"Project setup","\u002Fdocs\u002Fgetting-started\u002Fproject-setup","1.docs\u002F1.getting-started\u002F6.project-setup","i-lucide-package",false,{"title":39,"path":40,"stem":41,"children":42,"icon":45},"Core Concepts","\u002Fdocs\u002Fconcepts","1.docs\u002F2.concepts\u002F1.index",[43,46,51,56,61,66,71,76,81],{"title":44,"path":40,"stem":41,"icon":45},"Core concepts","i-lucide-book-open",{"title":47,"path":48,"stem":49,"icon":50},"Architecture","\u002Fdocs\u002Fconcepts\u002Farchitecture","1.docs\u002F2.concepts\u002F2.architecture","i-lucide-layers",{"title":52,"path":53,"stem":54,"icon":55},"Exactly-once semantics","\u002Fdocs\u002Fconcepts\u002Fexactly-once","1.docs\u002F2.concepts\u002F3.exactly-once","i-lucide-shield-check",{"title":57,"path":58,"stem":59,"icon":60},"Lanes and parallelism","\u002Fdocs\u002Fconcepts\u002Flanes-and-parallelism","1.docs\u002F2.concepts\u002F4.lanes-and-parallelism","i-lucide-split",{"title":62,"path":63,"stem":64,"icon":65},"State and thread-safety","\u002Fdocs\u002Fconcepts\u002Fstate-and-thread-safety","1.docs\u002F2.concepts\u002F5.state-and-thread-safety","i-lucide-lock",{"title":67,"path":68,"stem":69,"icon":70},"Event time and watermarks","\u002Fdocs\u002Fconcepts\u002Fevent-time-and-watermarks","1.docs\u002F2.concepts\u002F6.event-time-and-watermarks","i-lucide-clock",{"title":72,"path":73,"stem":74,"icon":75},"The configuration model","\u002Fdocs\u002Fconcepts\u002Fconfiguration-model","1.docs\u002F2.concepts\u002F7.configuration-model","i-lucide-sliders-horizontal",{"title":77,"path":78,"stem":79,"icon":80},"The error-handling model","\u002Fdocs\u002Fconcepts\u002Ferror-handling-model","1.docs\u002F2.concepts\u002F8.error-handling-model","i-lucide-triangle-alert",{"title":82,"path":83,"stem":84,"icon":85},"How StoatFlow differs from Kafka Streams","\u002Fdocs\u002Fconcepts\u002Fhow-stoatflow-differs-from-ks","1.docs\u002F2.concepts\u002F9.how-stoatflow-differs-from-ks","i-lucide-arrow-left-right",{"title":87,"path":88,"stem":89,"children":90,"icon":93},"Building Topologies","\u002Fdocs\u002Fbuilding","1.docs\u002F3.building\u002F1.index",[91,94,99,104,109,114,119,124,129,134,139,144],{"title":92,"path":88,"stem":89,"icon":93},"Building topologies","i-lucide-blocks",{"title":95,"path":96,"stem":97,"icon":98},"Error handling and DLQ","\u002Fdocs\u002Fbuilding\u002Ferror-handling-dlq","1.docs\u002F3.building\u002F10.error-handling-dlq","i-lucide-circle-x",{"title":100,"path":101,"stem":102,"icon":103},"State stores","\u002Fdocs\u002Fbuilding\u002Fstate-stores","1.docs\u002F3.building\u002F11.state-stores","i-lucide-database",{"title":105,"path":106,"stem":107,"icon":108},"Testing topologies","\u002Fdocs\u002Fbuilding\u002Ftesting","1.docs\u002F3.building\u002F12.testing","i-lucide-flask-conical",{"title":110,"path":111,"stem":112,"icon":113},"Sources and sinks","\u002Fdocs\u002Fbuilding\u002Fstreams-builder","1.docs\u002F3.building\u002F2.streams-builder","i-lucide-import",{"title":115,"path":116,"stem":117,"icon":118},"KStream and KTable operations","\u002Fdocs\u002Fbuilding\u002Fkstream-ktable","1.docs\u002F3.building\u002F3.kstream-ktable","i-lucide-waypoints",{"title":120,"path":121,"stem":122,"icon":123},"Aggregations","\u002Fdocs\u002Fbuilding\u002Faggregations","1.docs\u002F3.building\u002F4.aggregations","i-lucide-sigma",{"title":125,"path":126,"stem":127,"icon":128},"Windowing","\u002Fdocs\u002Fbuilding\u002Fwindowing","1.docs\u002F3.building\u002F5.windowing","i-lucide-calendar-clock",{"title":130,"path":131,"stem":132,"icon":133},"Joins","\u002Fdocs\u002Fbuilding\u002Fjoins","1.docs\u002F3.building\u002F6.joins","i-lucide-git-merge",{"title":135,"path":136,"stem":137,"icon":138},"The Processor API","\u002Fdocs\u002Fbuilding\u002Fprocessor-api","1.docs\u002F3.building\u002F7.processor-api","i-lucide-cpu",{"title":140,"path":141,"stem":142,"icon":143},"Scheduled sources","\u002Fdocs\u002Fbuilding\u002Fscheduled-sources","1.docs\u002F3.building\u002F8.scheduled-sources","i-lucide-timer",{"title":145,"path":146,"stem":147,"icon":148},"Serdes and Avro","\u002Fdocs\u002Fbuilding\u002Fserdes","1.docs\u002F3.building\u002F9.serdes","i-lucide-binary",{"title":150,"path":151,"stem":152,"children":153,"icon":75},"Configuration","\u002Fdocs\u002Fconfiguration","1.docs\u002F4.configuration\u002F1.index",[154,156,161,166,171],{"title":155,"path":151,"stem":152,"icon":75},"How configuration works",{"title":157,"path":158,"stem":159,"icon":160},"Engine configuration (:core)","\u002Fdocs\u002Fconfiguration\u002Fcore-config","1.docs\u002F4.configuration\u002F2.core-config","i-lucide-settings-2",{"title":162,"path":163,"stem":164,"icon":165},"Runtime configuration (:runtime)","\u002Fdocs\u002Fconfiguration\u002Fruntime-config","1.docs\u002F4.configuration\u002F3.runtime-config","i-lucide-server-cog",{"title":167,"path":168,"stem":169,"icon":170},"Defaults, adaptivity, and presets","\u002Fdocs\u002Fconfiguration\u002Fdefaults-and-presets","1.docs\u002F4.configuration\u002F4.defaults-and-presets","i-lucide-gauge",{"title":172,"path":173,"stem":174,"icon":175},"Kafka client configuration","\u002Fdocs\u002Fconfiguration\u002Fkafka-client-config","1.docs\u002F4.configuration\u002F5.kafka-client-config","i-lucide-plug",{"title":177,"path":178,"stem":179,"children":180,"icon":183},"Running in Production","\u002Fdocs\u002Fruntime","1.docs\u002F5.runtime\u002F1.index",[181,184,189,194,199,204,209,214],{"title":182,"path":178,"stem":179,"icon":183},"The runtime","i-lucide-server",{"title":185,"path":186,"stem":187,"icon":188},"The REST API","\u002Fdocs\u002Fruntime\u002Frest-api","1.docs\u002F5.runtime\u002F2.rest-api","i-lucide-globe",{"title":190,"path":191,"stem":192,"icon":193},"Health checks","\u002Fdocs\u002Fruntime\u002Fhealth-checks","1.docs\u002F5.runtime\u002F3.health-checks","i-lucide-heart-pulse",{"title":195,"path":196,"stem":197,"icon":198},"Metrics","\u002Fdocs\u002Fruntime\u002Fmetrics","1.docs\u002F5.runtime\u002F4.metrics","i-lucide-activity",{"title":200,"path":201,"stem":202,"icon":203},"Pause and resume","\u002Fdocs\u002Fruntime\u002Fpause-unpause","1.docs\u002F5.runtime\u002F5.pause-unpause","i-lucide-pause",{"title":205,"path":206,"stem":207,"icon":208},"Plugins and lifecycle hooks","\u002Fdocs\u002Fruntime\u002Fplugins","1.docs\u002F5.runtime\u002F6.plugins","i-lucide-puzzle",{"title":210,"path":211,"stem":212,"icon":213},"Docker images","\u002Fdocs\u002Fruntime\u002Fdocker","1.docs\u002F5.runtime\u002F7.docker","i-lucide-container",{"title":215,"path":216,"stem":217,"icon":218},"GraalVM native image","\u002Fdocs\u002Fruntime\u002Fnative-image","1.docs\u002F5.runtime\u002F8.native-image","i-lucide-zap",{"title":220,"path":221,"stem":222,"children":223,"icon":226},"Deploying & Operating","\u002Fdocs\u002Foperating","1.docs\u002F6.operating\u002F1.index",[224,227,232,237,242,247,252],{"title":225,"path":221,"stem":222,"icon":226},"Deploying and operating","i-lucide-life-buoy",{"title":228,"path":229,"stem":230,"icon":231},"Running on Kubernetes","\u002Fdocs\u002Foperating\u002Fkubernetes","1.docs\u002F6.operating\u002F2.kubernetes","i-lucide-ship",{"title":233,"path":234,"stem":235,"icon":236},"High availability","\u002Fdocs\u002Foperating\u002Fhigh-availability","1.docs\u002F6.operating\u002F3.high-availability","i-lucide-copy",{"title":238,"path":239,"stem":240,"icon":241},"Liveness and readiness probes","\u002Fdocs\u002Foperating\u002Fprobes","1.docs\u002F6.operating\u002F4.probes","i-lucide-stethoscope",{"title":243,"path":244,"stem":245,"icon":246},"Observability","\u002Fdocs\u002Foperating\u002Fobservability","1.docs\u002F6.operating\u002F5.observability","i-lucide-telescope",{"title":248,"path":249,"stem":250,"icon":251},"Tuning under load","\u002Fdocs\u002Foperating\u002Ftuning","1.docs\u002F6.operating\u002F6.tuning","i-lucide-sliders",{"title":253,"path":254,"stem":255,"icon":256},"Production checklist","\u002Fdocs\u002Foperating\u002Fproduction-checklist","1.docs\u002F6.operating\u002F7.production-checklist","i-lucide-clipboard-check",{"title":258,"path":259,"stem":260,"children":261,"icon":85},"Migrating from Kafka Streams","\u002Fdocs\u002Fmigration","1.docs\u002F7.migration\u002F1.index",[262,263,268],{"title":258,"path":259,"stem":260,"icon":85},{"title":264,"path":265,"stem":266,"icon":267},"Migration without carrying state","\u002Fdocs\u002Fmigration\u002Fwithout-data-migration","1.docs\u002F7.migration\u002F2.without-data-migration","i-lucide-sparkles",{"title":269,"path":270,"stem":271,"icon":272},"Migration carrying state","\u002Fdocs\u002Fmigration\u002Fwith-data-migration","1.docs\u002F7.migration\u002F3.with-data-migration","i-lucide-database-backup",{"title":274,"path":275,"stem":276,"children":277,"icon":279},"Reference","\u002Fdocs\u002Freference","1.docs\u002F8.reference\u002F1.index",[278,280,285,290,295,300,305,309],{"title":274,"path":275,"stem":276,"icon":279},"i-lucide-list",{"title":281,"path":282,"stem":283,"icon":284},"Configuration reference","\u002Fdocs\u002Freference\u002Fconfiguration-reference","1.docs\u002F8.reference\u002F2.configuration-reference","i-lucide-table",{"title":286,"path":287,"stem":288,"icon":289},"REST API reference","\u002Fdocs\u002Freference\u002Frest-api-reference","1.docs\u002F8.reference\u002F3.rest-api-reference","i-lucide-network",{"title":291,"path":292,"stem":293,"icon":294},"Gradle plugin reference","\u002Fdocs\u002Freference\u002Fgradle-plugin-reference","1.docs\u002F8.reference\u002F4.gradle-plugin-reference","i-lucide-box",{"title":296,"path":297,"stem":298,"icon":299},"Maven reference","\u002Fdocs\u002Freference\u002Fmaven-reference","1.docs\u002F8.reference\u002F5.maven-reference","i-simple-icons-apachemaven",{"title":301,"path":302,"stem":303,"icon":304},"Kafka Streams compatibility matrix","\u002Fdocs\u002Freference\u002Fks-compatibility-matrix","1.docs\u002F8.reference\u002F6.ks-compatibility-matrix","i-lucide-table-2",{"title":306,"path":307,"stem":308,"icon":170},"Metrics reference","\u002Fdocs\u002Freference\u002Fmetrics-reference","1.docs\u002F8.reference\u002F7.metrics-reference",{"title":310,"path":311,"stem":312,"icon":313},"Glossary","\u002Fdocs\u002Freference\u002Fglossary","1.docs\u002F8.reference\u002F8.glossary","i-lucide-book-a",{"id":315,"title":310,"body":316,"description":777,"extension":778,"meta":779,"navigation":780,"pageType":781,"path":311,"seo":782,"stem":312,"__hash__":783},"docs\u002F1.docs\u002F8.reference\u002F8.glossary.md",{"type":317,"value":318,"toc":745},"minimark",[319,323,328,333,341,345,354,358,363,367,377,381,387,391,405,409,421,425,434,438,447,451,460,464,487,491,496,500,522,526,534,538,547,551,566,570,590,594,611,615,633,637,646,650,666,670,689,693,707,711,721,725],[320,321,322],"p",{},"Definitions of the vocabulary used throughout the StoatFlow documentation. Each entry links to the page that covers the concept in depth.",[324,325,327],"h2",{"id":326},"concepts","Concepts",[329,330,332],"h3",{"id":331},"at-least-once-alo","At-least-once (ALO)",[320,334,335,336,340],{},"A delivery guarantee under which every record is processed at least once, but a crash may cause some records to be processed again and re-emitted downstream. StoatFlow's at-least-once mode drops the Kafka transaction: the runtime uses a non-transactional producer and commits consumer offsets directly, on a faster cadence. Trades duplicate-tolerance for a lower latency floor. See ",[337,338,339],"a",{"href":53},"Exactly-once and at-least-once",".",[329,342,344],{"id":343},"changelog","Changelog",[320,346,347,348,350,351,353],{},"A compacted Kafka topic that records every write to a state store. Because the topic is compacted by key, the latest value for every key is preserved indefinitely without unbounded growth. On restart, the runtime rebuilds local state by reading the changelog. See ",[337,349,100],{"href":101}," and the ",[337,352,47],{"href":48}," page.",[329,355,357],{"id":356},"commit-barrier","Commit barrier",[320,359,360,361,340],{},"A marker — not a data record — that the runtime periodically injects into the processing lanes. As records flow through the topology the barrier flows with them; when every lane has reached it, the runtime executes one Kafka transaction that atomically commits the epoch's state writes, output records, and input offsets. The mechanism belongs to the Chandy-Lamport family of distributed-snapshot algorithms (the same lineage as Flink's checkpoint barriers), scoped to a single process. See ",[337,362,339],{"href":53},[329,364,366],{"id":365},"dead-letter-queue-dlq","Dead-letter queue (DLQ)",[320,368,369,370,374,375,340],{},"A Kafka topic that receives records the pipeline could not handle — deserialization failures, processing exceptions, or production errors — when the corresponding exception handler is configured with one. The failed record is preserved together with error-context headers (the ",[371,372,373],"code",{},"__stoatflow.errors.*"," namespace) for offline inspection or replay, while the topology keeps processing. See ",[337,376,95],{"href":96},[329,378,380],{"id":379},"epoch","Epoch",[320,382,383,384,340],{},"The unit of work bounded by two consecutive commit barriers — all the records processed, state written, and output produced between one commit and the next. Either an epoch commits atomically or, on a crash, its partial work is aborted and reprocessed. Epoch size and commit cadence self-tune within configured bounds; see ",[337,385,386],{"href":249},"Tuning",[329,388,390],{"id":389},"event-time","Event time",[320,392,393,394,397,398,402,403,340],{},"The time at which an event actually occurred, carried on the record itself — the Kafka record timestamp by default, or whatever a custom ",[371,395,396],{},"TimestampExtractor"," returns. Stateful operators that reason about time (windowed aggregations, session windows, time-bounded joins) use event time, not arrival time. Contrast with ",[399,400,401],"strong",{},"processing time",". See ",[337,404,67],{"href":68},[329,406,408],{"id":407},"exactly-once-eos","Exactly-once (EOS)",[320,410,411,412,415,416,402,419,340],{},"A guarantee that each input record affects state and produces output exactly once, even across crashes. StoatFlow achieves it with the commit barrier: state writes, sink output, and consumer offsets commit together in a single Kafka transaction, or not at all. Downstream consumers reading with ",[371,413,414],{},"read_committed"," isolation never see duplicates. Contrast with ",[399,417,418],{},"at-least-once",[337,420,339],{"href":53},[329,422,424],{"id":423},"grace-period","Grace period",[320,426,427,428,431,432,340],{},"A configurable interval, set on a window specification (for example ",[371,429,430],{},"TimeWindows.ofSizeAndGrace(...)","), during which late records are still folded into a window after the watermark has passed the window's end. Once the grace period elapses the window closes and later records that would have belonged to it are dropped. See ",[337,433,125],{"href":126},[329,435,437],{"id":436},"hot-standby","Hot standby",[320,439,440,441,444,445,340],{},"An opt-in high-availability mode (",[371,442,443],{},"stoatflow.ha.mode: active-standby",") that runs the application as a cluster of one active instance plus one or more passive warm standbys: the active processes and commits while each standby continuously follows the changelog and stays warm; on failover a lag-aware election promotes the freshest, ready in seconds. It adds redundancy without changing the single-active-instance model. See ",[337,446,233],{"href":234},[329,448,450],{"id":449},"key-affinity-lane","Key-affinity lane",[320,452,453,454,457,458,340],{},"A unit of concurrent processing inside the single JVM. Each lane runs the full topology independently against the shared state stores. Records are routed to lanes by ",[399,455,456],{},"key affinity"," — the same key always goes to the same lane — which guarantees per-key ordering while letting different keys process in parallel. Lane count is configured independently of Kafka partition count and scales with CPU cores. See ",[337,459,57],{"href":58},[329,461,463],{"id":462},"keyed-timer-timerservice","Keyed timer (TimerService)",[320,465,466,467,470,471,474,475,478,479,482,483,340],{},"A one-shot, per-key callback registered from a custom ",[371,468,469],{},"Processor"," through ",[371,472,473],{},"TimerService"," — a Flink-inspired extension. A timer fires ",[371,476,477],{},"onTimer(...)"," for a specific key at a specific instant, in event time (when the watermark passes it) or processing time, in the same per-key serialized context as ",[371,480,481],{},"process(...)"," and with full state access. With the persistent (RocksDB) timer backend, pending timers survive restarts. See ",[337,484,486],{"href":485},"\u002Fdocs\u002Fbuilding\u002Fprocessor-api#timers","Processor API → Timers",[329,488,490],{"id":489},"late-record","Late record",[320,492,493,494,340],{},"A record whose event time is older than the current watermark. While its window remains within its grace period, a late record still updates the window's result; after the window has closed it is dropped. See ",[337,495,67],{"href":68},[329,497,499],{"id":498},"materialized","Materialized",[320,501,502,503,505,506,509,510,509,513,516,517,519,520,340],{},"The configuration object (",[371,504,499],{},") that tells a stateful DSL operator to back its result with a named, queryable state store — controlling the store name, store type, serdes, caching, and changelog. Operators like ",[371,507,508],{},"count",", ",[371,511,512],{},"reduce",[371,514,515],{},"aggregate",", and table transforms accept a ",[371,518,499],{}," to expose their result as a store. See ",[337,521,100],{"href":101},[329,523,525],{"id":524},"processing-time","Processing time",[320,527,528,529,402,532,340],{},"The wall-clock time at which a record is processed by the runtime, independent of when the underlying event occurred. Used by processing-time timers and as the default clock when no event-time semantics are configured. Contrast with ",[399,530,531],{},"event time",[337,533,67],{"href":68},[329,535,537],{"id":536},"promotion-token","Promotion token",[320,539,540,541,544,545,340],{},"A single record on the ",[337,542,436],{"href":543},"#hot-standby"," coordination topic, claimed by compare-and-set, that authorizes exactly one standby to promote during a failover election. A standby that loses the claim stands down and remains a standby — no fence, no restart. Under exactly-once the token is the election layer and Kafka's producer-epoch fence remains the safety backstop; under at-least-once the token itself is the fence. See ",[337,546,233],{"href":234},[329,548,550],{"id":549},"punctuator","Punctuator",[320,552,553,554,557,558,561,562,340],{},"A periodic callback scheduled by a processor via ",[371,555,556],{},"context.schedule(...)",", firing on stream time (watermark advance) or wall-clock time — useful for heartbeats, metrics, or flushing buffered state. Punctuators run on a dedicated punctuation lane per sub-topology with full state access, concurrently with record processing; for per-key work in the record-serialized context, use a ",[399,559,560],{},"keyed timer"," instead. See ",[337,563,565],{"href":564},"\u002Fdocs\u002Fbuilding\u002Fprocessor-api#punctuators","Processor API → Punctuators",[329,567,569],{"id":568},"repartition","Repartition",[320,571,572,573,509,576,579,580,583,584,587,588,340],{},"Re-routing a record to a different lane because an operation changed its key — ",[371,574,575],{},"selectKey",[371,577,578],{},"groupBy",", or a key-changing ",[371,581,582],{},"map","\u002F",[371,585,586],{},"flatMap","\u002Fjoin. In standard Kafka Streams this requires writing to and re-reading from an internal repartition topic; in StoatFlow it happens in-memory between lanes, with no broker round-trip and no extra serialization. See ",[337,589,57],{"href":58},[329,591,593],{"id":592},"scheduled-source","Scheduled source",[320,595,596,597,600,601,604,605,608,609,340],{},"A topology-level source that emits records on a clock instead of consuming from Kafka — ",[371,598,599],{},"StreamsBuilder.scheduled(...)"," returns a normal ",[371,602,603],{},"KStream"," for downstream processing. Supports fixed intervals (stream-time or wall-clock) and cron expressions (",[371,606,607],{},"CronExpression.unix\u002Fquartz\u002Fspring",", always wall-clock). A StoatFlow extension with no Kafka Streams equivalent. See ",[337,610,140],{"href":141},[329,612,614],{"id":613},"serde","Serde",[320,616,617,618,509,621,509,624,509,626,629,630,340],{},"A serializer\u002Fdeserializer pair that converts between typed keys\u002Fvalues and the byte form Kafka stores. Source topics, sink topics, and state stores each need serdes for their key and value types; the DSL supplies defaults and per-operator overrides (",[371,619,620],{},"Consumed",[371,622,623],{},"Produced",[371,625,499],{},[371,627,628],{},"Grouped","). See ",[337,631,632],{"href":146},"Serdes",[329,634,636],{"id":635},"state-store","State store",[320,638,639,640,642,643,340],{},"A keyed store that stateful operators read and write. StoatFlow ships several types — key-value, window, session, versioned (timestamped lookups), and timer — each in a RocksDB-backed (persistent) or in-memory variant. State is global: every store lives in the one JVM and any lane can read or write any key, with correctness guaranteed by key affinity. Durability comes from the changelog. See ",[337,641,100],{"href":101}," and ",[337,644,645],{"href":63},"State and thread safety",[329,647,649],{"id":648},"sub-topology","Sub-topology",[320,651,652,653,509,655,657,658,583,660,662,663,665],{},"A segment of a topology bounded by a re-keying operation. A key-changing operator (",[371,654,575],{},[371,656,578],{},", a key-changing ",[371,659,582],{},[371,661,586],{},", or a repartition) marks a sub-topology boundary, because records cross it under a new key. A topology with no re-keying is a single sub-topology; each additional re-key adds one. The boundary is what determines where repartitioning occurs. See ",[337,664,120],{"href":121}," for where the boundary appears in practice.",[329,667,669],{"id":668},"suppression","Suppression",[320,671,672,673,676,677,680,681,684,685,340],{},"Holding a windowed aggregation's intermediate updates and emitting only the final result — declaratively via ",[371,674,675],{},"EmitStrategy.onWindowClose()",", or with explicit buffer control via ",[371,678,679],{},"KTable.suppress(Suppressed.untilWindowCloses(...))"," \u002F ",[371,682,683],{},"untilTimeLimit(...)",". Suppressed results flush when the watermark closes the window. See ",[337,686,688],{"href":687},"\u002Fdocs\u002Fbuilding\u002Fwindowing#suppression","Windowing → Suppression",[329,690,692],{"id":691},"topology","Topology",[320,694,695,696,699,700,702,703,642,705,340],{},"The directed graph of source nodes, processors, and sink nodes that defines a stream-processing application — built with ",[371,697,698],{},"StreamsBuilder"," (high-level DSL) or ",[371,701,692],{}," directly (Processor API). The runtime executes the same topology independently in every lane. See ",[337,704,698],{"href":111},[337,706,47],{"href":48},[329,708,710],{"id":709},"watermark","Watermark",[320,712,713,714,718,719,340],{},"A claim made by the runtime that no further records earlier than a given time are expected: \"I do not expect any record older than ",[715,716,717],"em",{},"T",".\" Watermarks are tracked per source partition and combined into a single global watermark for the application. When the global watermark passes a window's end (plus its grace period), the window closes. The watermark advances together with the commit barrier so windowed results commit alongside the watermark progress that produced them. See ",[337,720,67],{"href":68},[324,722,724],{"id":723},"see-also","See also",[726,727,728,734,739],"ul",{},[729,730,731,733],"li",{},[337,732,47],{"href":48}," — how these concepts fit together in the single-instance engine",[729,735,736,738],{},[337,737,82],{"href":83}," — where StoatFlow's model diverges from the terms' Kafka Streams meaning",[729,740,741,744],{},[337,742,743],{"href":302},"KS compatibility matrix"," — DSL operator parity",{"title":746,"searchDepth":747,"depth":747,"links":748},"",2,[749,776],{"id":326,"depth":747,"text":327,"children":750},[751,753,754,755,756,757,758,759,760,761,762,763,764,765,766,767,768,769,770,771,772,773,774,775],{"id":331,"depth":752,"text":332},3,{"id":343,"depth":752,"text":344},{"id":356,"depth":752,"text":357},{"id":365,"depth":752,"text":366},{"id":379,"depth":752,"text":380},{"id":389,"depth":752,"text":390},{"id":407,"depth":752,"text":408},{"id":423,"depth":752,"text":424},{"id":436,"depth":752,"text":437},{"id":449,"depth":752,"text":450},{"id":462,"depth":752,"text":463},{"id":489,"depth":752,"text":490},{"id":498,"depth":752,"text":499},{"id":524,"depth":752,"text":525},{"id":536,"depth":752,"text":537},{"id":549,"depth":752,"text":550},{"id":568,"depth":752,"text":569},{"id":592,"depth":752,"text":593},{"id":613,"depth":752,"text":614},{"id":635,"depth":752,"text":636},{"id":648,"depth":752,"text":649},{"id":668,"depth":752,"text":669},{"id":691,"depth":752,"text":692},{"id":709,"depth":752,"text":710},{"id":723,"depth":747,"text":724},"Concise definitions of the terms used across the StoatFlow docs — lanes, commit barriers, epochs, watermarks, event time, changelog, state stores, serdes, repartitioning, and exactly-once.","md",{},{"icon":313},"reference",{"title":310,"description":777},"D0p5knohmpRTLhYjMDgqGWL_G0TsLTr8YtJ92py-8CM",[785,787],{"title":306,"path":307,"stem":308,"description":786,"icon":170,"children":-1},"The full catalogue of Prometheus meters StoatFlow exposes on \u002Fmetrics — name, type, tags, and what each one measures, grouped by area.",null,1783713365503]