APACHE FLINK · INDEPENDENT ENGINEERING
Assess, design and operate self-managed Apache Flink for continuous processing, with state, checkpoints and upgrades tested against your own jobs before they reach production.
Independent Apache Flink engineering.
These are independent Bassirah engineering and support offerings. They do not imply upstream vendor or foundation endorsement, official vendor support rights, enterprise feature entitlement or maintenance guarantees.
Apache Flink, Flink and the Flink logo are trademarks of The Apache Software Foundation. Apache is a trademark of The Apache Software Foundation.
Supported releases.
Apache Flink is a project of The Apache Software Foundation, released under the Apache License 2.0. Bassirah provides independent engineering for the Flink 2.3 and Flink 2.2 release lines, and for the Flink 1.20 line that the project labels LTS, and plans upgrades from earlier lines. The exact versions in scope are named in each statement of work. Last reviewed: 26 October 2026.
| Release line | Status on 26 October 2026 | How Bassirah treats it |
|---|---|---|
| Flink 2.3 | Latest stable release: 2.3.0, 25 June 2026 | Default target for new deployments and upgrades, once the connectors you depend on list support for it |
| Flink 2.2 | Previous minor release; latest 2.2.1, 15 May 2026 | Supported; plan the move to 2.3 within the community's support window |
| Flink 2.1 and 2.0 | Older 2.x lines; latest 2.1.3 (14 June 2026) and 2.0.2 (11 May 2026) | Upgrade planning to 2.2 or 2.3 |
| Flink 1.20 (LTS) | Labeled LTS in the project's documentation; latest 1.20.5, 3 June 2026 | Supported while you plan the major upgrade to 2.x; no end date is published by the project |
| Flink 1.19 and earlier | Last 1.19 release 1.19.3, 10 July 2025 | Upgrade assessment: move to 1.20 first or plan a direct move to 2.x |
WHY IT MATTERS
Apache Flink is a distributed engine for stateful computations over unbounded and bounded data streams. It lets teams filter, join, aggregate and enrich events as they arrive, instead of waiting for the next batch.
The engine keeps state for each job, such as windows, counters and joined records, and takes periodic checkpoints of that state to durable storage. After a failure, a job restarts from its last completed checkpoint, so results stay consistent. That design moves the hard problems into state size, checkpoint behavior, event-time handling, backpressure and upgrades. The 2.x line also changed APIs, configuration and serialization, and the project does not promise state compatibility between 1.x and 2.x. Bassirah tests these behaviors with your own jobs and data before you commit, and engineers the platform so that it holds up in production.
WHAT BASSIRAH DELIVERS
FIT FIRST
A stream processing engine adds moving parts. We recommend Apache Flink when the workload needs what it provides, and we say so when a simpler consumer or a scheduled batch job is enough.
| Requirement | Apache Flink is worth evaluating when… | A simpler option is often enough when… |
|---|---|---|
| Freshness | Results must update continuously as events arrive | Results refreshed on a schedule meet the business need |
| State | Jobs must join streams, keep windows or track per-key state over time | Each event can be handled on its own, without memory of earlier events |
| Time semantics | Results must follow event time, including late and out-of-order events | Processing time is good enough for the result |
| Consistency on failure | State and results must stay consistent after a restart, with checkpoints to durable storage | Reprocessing or occasional duplicates are acceptable and easy to handle |
| Operations | Your team, or a contracted provider, will operate a distributed, stateful system | You want the smallest possible operational footprint |
Batch-first or mixed workloads? See our Apache Spark engineering page. Moving events between systems without heavy processing? See Apache Kafka. We test each option against your workload before recommending one.
STATE AND RECOVERY
Flink keeps job state in a state backend, writes checkpoints to durable storage and can recover a failed JobManager through its high availability services. Savepoints, taken on demand, carry state across upgrades and changes. Each choice trades cost, recovery behavior and operational effort differently. We choose them per job, then prove the effect of a TaskManager, JobManager or zone failure in tested recovery exercises against objectives you approve.
| Decision | Typical approach | Trade-off we make explicit |
|---|---|---|
| State backend | HashMap state on the heap for small state; RocksDB on local disk for large state; the disaggregated ForSt backend only after testing, as the project marks it experimental | Memory use and access speed vs. state size and checkpoint behavior |
| Checkpoints | Periodic checkpoints to object storage or a distributed file system, with interval and timeouts set per job | Recovery point and restart work vs. checkpoint overhead on the running job |
| Savepoints | Savepoints before every upgrade or job change, with explicit operator IDs so state maps back to operators | Upgrade safety vs. the discipline of keeping IDs and state types stable |
| JobManager availability | Kubernetes or ZooKeeper high availability services, with HA metadata on durable storage | Fewer interruptions from JobManager loss vs. extra components to operate |
| Restarts and rescaling | Restart strategies and parallelism set per job, with rescaling from checkpoints or savepoints | Faster recovery and right-sized jobs vs. reprocessing and state redistribution on restart |
OPERATIONS
Size state per operator, choose the state backend and tune checkpoint intervals, timeouts and storage based on measured behavior.
Find the operators that slow a pipeline, then adjust parallelism, partitioning and resources based on evidence.
Savepoint-based upgrades with checks for APIs, connectors and configuration, rehearsed in staging with a rollback decision point.
Checkpoint health, backpressure, consumer lag, restarts and resource use with actionable alerts, plus savepoint and restore drills.
UPGRADE AND MIGRATION
Delivered through our migration and modernization practice, for jobs moving from Flink 1.x to 2.x or from other stream processing tools.
Start with a compatibility review of your jobs, connectors and state.
USE CASES
Continuous aggregation and enrichment of event streams before they land in an analytical store for dashboards and alerts.
Stateful rules and pattern detection over event streams, such as fraud and risk signals, with results tested against historical data.
Moving and transforming database changes and events into lakehouse tables and downstream systems as they happen.
SUPPORT ROUTES
Apache Flink is open source and developed by its community at The Apache Software Foundation. Several companies offer commercial Flink products and services, including Ververica (the Unified Streaming Data Platform, in BYOC and self-managed options), Confluent (Confluent Cloud for Apache Flink, a managed service) and Amazon Web Services (Amazon Managed Service for Apache Flink). Bassirah is not a partner of Ververica, Confluent or Amazon Web Services. We support the open-source project independently and are clear about where our commitments end.
| Decision factor | Community only | Bassirah independent support | Vendor product or managed service |
|---|---|---|---|
| Who operates Apache Flink | Your team | Your team with Bassirah engineering, or Bassirah under a managed scope | The vendor or cloud provider, or your team with the vendor's platform, under the vendor's terms |
| Help with incidents | Public community channels, no response commitment | Response targets per your agreement | Vendor support under the vendor's own terms |
| Code defects | Reported by you to the project | Reproduced, worked around and reported upstream by Bassirah | Handled by the vendor under its terms |
| Upstream fixes and releases | On the project's timeline | On the project's timeline; we track them, test them and apply them through change control | On the vendor's release schedule; supported versions and features can differ from open-source Flink |
| Commercial products | Not included | Not included: Bassirah does not resell or license vendor Flink products or services | Contracted directly with the vendor |
If you need a vendor-backed platform or a managed Flink service, that is contracted with the vendor. How cases, severities and response targets work for our independent support is set out in our open-source support model. For fully contracted operations, see Managed Services.
WORKS WITH
Apache Flink is one part of our streaming and real-time data practice. We place it alongside event streaming, analytical serving and object storage where each fits, and test every integration first.
Durable event streams as a source and sink for Flink jobs, with topic design and consumer behavior tested together.
Analytical serving for results that Flink produces, where dashboards need fast queries on fresh data.
S3-compatible object storage for checkpoints, savepoints and lakehouse tables, after testing with your Flink version.
Contracted operations, monitoring and incident handling for Flink estates.
Yes. Apache Flink is a project of The Apache Software Foundation, released under the Apache License 2.0. Vendor platforms and managed Flink services are separate commercial offerings. Bassirah supports the open-source project and is not endorsed by the ASF or the Flink project.
Not automatically. The project’s release notes say state compatibility between 1.x and 2.x is not assured. Flink 2.0 also removed several APIs and the old flink-conf.yaml file. We review each job and decide whether its state can be restored, must be rebuilt or needs a different design.
When results refreshed on a schedule meet the need, when events can be handled one at a time without state, or when reprocessing is acceptable after a failure. A scheduled batch job or a plain consumer is simpler to operate. See our Apache Spark and Apache Kafka pages.
We work on the Flink 2.3 and 2.2 lines and on the 1.20 line that the project labels LTS, and we plan upgrades from earlier lines. The project gives bugfixes to the current and previous minor releases. The versions in scope are confirmed in each statement of work.
No. Bassirah is not a partner of Ververica, Confluent or Amazon Web Services, and does not provide vendor support, vendor security fixes or vendor escalation. Our services are independent engineering and support, with scope and response targets defined in your agreement. Code fixes and releases follow the project’s timeline. See our support model.
Flink takes periodic checkpoints of job state to durable storage and restarts jobs from the last completed checkpoint. JobManager high availability uses Kubernetes or ZooKeeper services. We design these per job and test the effect of losing a TaskManager, a JobManager or a zone.
Tell us about your jobs, state and recovery objectives. We will scope a fit assessment and a practical next step.
Operations & Reliability
Flink 2.x removed APIs and changed configuration and serialization. Plan the move from 1.20 job by job, with state as the main decision.
Apache Flink
Read article : Moving From Apache Flink 1.20 to 2.x: API, Configuration and State Planning→
