This is an automated email from the ASF dual-hosted git repository.
sk0x50 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ignite-website.git
The following commit(s) were added to refs/heads/master by this push:
new 1a9ecd37a7 IGNITE-27116 Part 1 of AI 3 architecture blog (#288)
1a9ecd37a7 is described below
commit 1a9ecd37a78e62d4772d8441f691c00454ab1fbe
Author: jinxxxoid <[email protected]>
AuthorDate: Tue Nov 25 20:59:28 2025 +0400
IGNITE-27116 Part 1 of AI 3 architecture blog (#288)
---
_src/_blog/apache-ignite-3-architecture-part-1.pug | 363 +++++++++++++++
...ml => apache-ignite-3-architecture-part-1.html} | 498 +++++++++++++--------
blog/apache/index.html | 39 +-
blog/ignite/index.html | 43 +-
blog/index.html | 43 +-
5 files changed, 732 insertions(+), 254 deletions(-)
diff --git a/_src/_blog/apache-ignite-3-architecture-part-1.pug
b/_src/_blog/apache-ignite-3-architecture-part-1.pug
new file mode 100644
index 0000000000..d82b99df73
--- /dev/null
+++ b/_src/_blog/apache-ignite-3-architecture-part-1.pug
@@ -0,0 +1,363 @@
+---
+title: "Apache Ignite Architecture Series: Part 1 - When Multi-System
Complexity Compounds at Scale"
+author: "Michael Aglietti"
+date: 2025-11-25
+tags:
+ - apache
+ - ignite
+---
+
+p Apache Ignite shows what really happens once your #[em good enough]
multi-system setup starts cracking under high-volume load. This piece breaks
down why the old stack stalls at scale and how a unified, memory-first
architecture removes the latency tax entirely.
+
+<!-- end -->
+
+p Your high-velocity application started with smart architectural choices.
PostgreSQL for reliable transactions, Redis for fast cache access, custom
processing for specific business logic. These decisions enabled initial success
and growth.
+
+p But success changes the game. Your application now processes thousands of
events per second and customers expect microsecond response times. Real-time
insights drive competitive advantage. The same architectural choices that
enabled growth now create performance bottlenecks that compound with every
additional event.
+
+p.
+ #[strong At high event volumes, data movement between systems becomes the
primary performance constraint].
+
+hr
+
+h3 The Scale Reality for High-Velocity Applications
+
+p As event volume grows, architectural compromises that once seemed reasonable
at lower scale become critical bottlenecks. Consider a financial trading
platform, gaming backend, or IoT processor handling tens of thousands of
operations per second.
+
+h3 Event Processing Under Pressure
+
+p #[strong High-frequency event characteristics]
+ul
+ li Events arrive faster than traditional batch processing can handle
+ li Each event requires immediate consistency checks against live data
+ li Results must update multiple downstream systems simultaneously
+ li Network delays compound into user-visible lag
+ li #[strong Traffic spikes create systemic pressure] — traditional stacks
drop connections or crash when overwhelmed
+
+p #[strong The compounding effect]
+ul
+ li At 100 events per second, network latency of 2ms adds minimal overhead.
+ li At 10,000 events per second, that same 2ms latency creates a 20-second
processing backlog within system boundaries.
+ li During traffic spikes (50,000+ events per second), traditional systems
collapse entirely, dropping connections and losing data when they're needed
most.
+p The math scales against you.
+
+hr
+
+h3 When Smart Choices Become Scaling Limits
+
+p #[strong Initial Architecture, works great at lower scale:]
+
+pre.mermaid.
+ flowchart TB
+ subgraph "Event Processing"
+ Events[High-Volume Events<br/>10,000/sec]
+ end
+
+ subgraph "Multi-System Architecture"
+ Redis[(Cache<br/>Session Data<br/>2ms latency)]
+ PostgreSQL[(Relational DB<br/>Transaction Data<br/>5ms latency)]
+ Processing[Custom Processing<br/>Business Logic<br/>3ms latency]
+ end
+
+ Events --> Redis
+ Events --> PostgreSQL
+ Events --> Processing
+
+ Redis <-->|Sync Overhead| PostgreSQL
+ PostgreSQL <-->|Data Movement| Processing
+ Processing <-->|Cache Updates| Redis
+
+p #[strong What happens at scale]
+ul
+ li #[strong Network-latency tax:] Every system hop adds milliseconds that
compound
+ li #[strong Synchronization delays:] Keeping systems consistent creates
processing queues
+ li #[strong Memory overhead:] Each system caches the same data in different
formats
+ li #[strong Consistency windows:] Brief periods where systems show different
data states
+
+hr
+
+h3 The Hidden Cost of Multi-System Success
+
+p #[strong Data Movement Overhead:]
+
+p Your events don't just need processing, they need processing that maintains
consistency across all systems.
+
+p Each event triggers:
+ul
+ li #[strong Cache lookup (Redis):] ≈ 0.5 ms network + processing
+ li #[strong Transaction validation (PostgreSQL):] ≈ 2 ms network + disk I/O
+ li #[strong Business-logic execution (Custom):] ≈ 1ms processing + data
marshalling
+ li #[strong Result synchronization (across systems):] ≈ 3 ms coordination
overhead
+
+p #[strong Minimum per-event cost ≈ 7 ms before business logic.]
+p At 10,000 events/s, you’d need 70 seconds of processing capacity just
#[strong for data movement] per real-time second!
+
+hr
+
+h3 The Performance Gap That Grows With Success
+
+h3 Why Traditional Options Fail
+
+p #[strong Option 1: Scale out each system]
+ul
+ li #[strong Strategy]: Add cache clusters, database replicas, processing
nodes
+ li #[strong Result]: More systems to coordinate, exponentially more
complexity
+ li #[strong Reality]: Network overhead grows faster than processing capacity
+
+p #[strong Option 2: Custom optimization]
+ul
+ li #[strong Strategy]: Build application-layer caching, custom consistency
protocols
+ li #[strong Result]: Engineering team maintains complex, system-specific
optimizations
+ li #[strong Reality]: Solutions don't generalize; each optimization creates
technical debt
+
+p #[strong Option 3: Accept compromises]
+ul
+ li #[strong Strategy]: Use async processing, eventual consistency, and
accept delayed insights
+ li #[strong Result]: Business requirements compromised to fit architectural
limitations
+ li #[strong Reality]: Competitive disadvantage as customer expectations grow
+
+hr
+
+h3 The Critical Performance Gap
+
+table(style="borderlicollapse: collapse; margin: 20px 0; width: 100%;")
+ thead
+ tr
+ th(style="border: 1px solid #ddd; padding: 12px; background-color:
#f5f5f5; text-align: left;") Component
+ th(style="border: 1px solid #ddd; padding: 12px; background-color:
#f5f5f5; text-align: left;") Optimized for
+ th(style="border: 1px solid #ddd; padding: 12px; background-color:
#f5f5f5; text-align: left;") Typical Latency
+ tbody
+ tr
+ td(style="border: 1px solid #ddd; padding: 12px;") Database
+ td(style="border: 1px solid #ddd; padding: 12px;") ACID transactions
+ td(style="border: 1px solid #ddd; padding: 12px;") Milliseconds
+ tr
+ td(style="border: 1px solid #ddd; padding: 12px;") Cache
+ td(style="border: 1px solid #ddd; padding: 12px;") Access speed
+ td(style="border: 1px solid #ddd; padding: 12px;") Microseconds
+ tr
+ td(style="border: 1px solid #ddd; padding: 12px;") Compute
+ td(style="border: 1px solid #ddd; padding: 12px;") Throughput
+ td(style="border: 1px solid #ddd; padding: 12px;") Minutes – hours
+
+
+p Applications needing #[strong microsecond insights] on #[strong millisecond
transactions] have no good options at scale in traditional architectures.
+
+p During traffic spikes, traditional architectures either drop connections
(data loss) or degrade performance (missed SLAs). High-velocity applications
need intelligent flow control that guarantees stability under pressure while
preserving data integrity.
+
+hr
+
+h3 Event Processing at Scale
+
+p #[strong Here's what traditional multi-system event processing costs:]
+
+pre
+ code.
+ // Traditional multi-system event processing
+ long startTime = System.nanoTime();
+
+ // 1. Cache lookup for session data
+ String sessionData = redisClient.get("session:" + eventId); // ~500μs
network
+ if (sessionData == null) {
+ sessionData = postgresDB.query("SELECT * FROM sessions WHERE id = ?",
eventId); // ~2ms fallback
+ redisClient.setex("session:" + eventId, 300, sessionData); // ~300μs
cache update
+ }
+
+ // 2. Transaction processing
+ postgresDB.executeTransaction(tx -> { // ~2-5ms transaction
+ tx.execute("INSERT INTO events VALUES (?, ?, ?)", eventId, userId,
eventData);
+ tx.execute("UPDATE user_stats SET event_count = event_count + 1 WHERE
user_id = ?", userId);
+ });
+
+ // 3. Custom processing with consistency coordination
+ ProcessingResult result = customProcessor.process(eventData, sessionData);
// ~1ms processing
+ redisClient.setex("result:" + eventId, 600, result); // ~300μs result
caching
+
+ // 4. Synchronization across systems
+ ensureConsistency(eventId, sessionData, result); // ~2-3ms coordination
+
+ long totalTime = System.nanoTime() - startTime;
+ // Total: 6-12ms per event (not including queuing delays)
+
+
+p #[strong Compound Effect at Scale:]
+
+table(style="border-collapse: collapse; margin: 20px 0; width: 100%;")
+ thead
+ tr
+ th(style="border: 1px solid #ddd; padding: 12px; background-color:
#f5f5f5; text-align: left;") Rate
+ th(style="border: 1px solid #ddd; padding: 12px; background-color:
#f5f5f5; text-align: left;") Required processing time / s
+ tbody
+ tr
+ td(style="border: 1px solid #ddd; padding: 12px;") 1,000 events / s
+ td(style="border: 1px solid #ddd; padding: 12px;") 6–12 s
+ tr
+ td(style="border: 1px solid #ddd; padding: 12px;") 5,000 events / s
+ td(style="border: 1px solid #ddd; padding: 12px;") 30–60 s
+ tr
+ td(style="border: 1px solid #ddd; padding: 12px;") 10,000 events / s
+ td(style="border: 1px solid #ddd; padding: 12px;") 60–120 s
+
+p #[strong The math doesn’t work:] parallelism helps, but coordination
overhead grows exponentially with system count.
+
+hr
+
+h3 Real-World Breaking Points
+ul
+ li #[strong Financial services]: Trading platforms hitting 10,000+
trades/second discover that compliance reporting delays impact trading
decisions.
+ li #[strong Gaming platforms]: Multiplayer backends processing user actions
find that leaderboard updates lag behind gameplay events.
+ li #[strong IoT analytics]: Manufacturing systems processing sensor data
realize that anomaly detection arrives too late for preventive action.
+
+hr
+
+h3 The Apache Ignite Alternative
+
+h3 Eliminating Multi-System Overhead
+
+pre.mermaid.
+ flowchart TB
+ subgraph "Event Processing"
+ Events[High-Volume Events<br/>10,000/sec]
+ end
+
+ subgraph "Apache Ignite Platform"
+ subgraph "Collocated Processing"
+ Memory[Memory-First Storage<br/>Optimized Access Times]
+ Transactions[MVCC Transactions<br/>ACID Guarantees]
+ Compute[Event Processing<br/>Where Data Lives]
+ end
+ end
+
+ Events --> Memory
+ Memory --> Transactions
+ Transactions --> Compute
+
+ Memory <-->|Minimal Copying| Transactions
+ Transactions <-->|Collocated| Compute
+ Compute <-->|Direct Access| Memory
+
+p #[strong Key difference:] events process #[strong where the data lives],
eliminating inter-system latency.
+
+hr
+
+h3 Apache Ignite Performance Reality Check
+
+p #[strong Here's the same event processing with integrated architecture:]
+
+pre
+ code.
+ // Apache Ignite integrated event processing
+ try (IgniteClient client =
IgniteClient.builder().addresses("cluster:10800").build()) {
+ // Single integrated transaction spanning cache, database, and compute
+ client.transactions().runInTransaction(tx -> {
+ // 1. Access session data (in memory, no network overhead)
+ Session session = client.tables().table("sessions")
+ .keyValueView().get(tx, Tuple.create().set("id", eventId));
+
+ // 2. Process event with ACID guarantees (same memory space)
+ client.sql().execute(tx, "INSERT INTO events VALUES (?, ?, ?)",
+ eventId, userId, eventData);
+
+ // 3. Execute processing collocated with data
+ ProcessingResult result = client.compute().execute(
+ JobTarget.colocated("events", Tuple.create().set("id",
eventId)),
+ EventProcessor.class, eventData);
+
+ // 4. Update derived data (same transaction, guaranteed
consistency)
+ client.sql().execute(tx, "UPDATE user_stats SET event_count =
event_count + 1 WHERE user_id = ?", userId);
+
+ return result;
+ });
+ }
+ // Result: microsecond-range event processing through integrated
architecture
+
+p Processing 10,000 events/s is achievable with integrated architecture
eliminating network overhead.
+
+hr
+
+h3 The Unified Data-Access Advantage
+
+p #[strong Here's what eliminates the need for separate systems:]
+
+pre
+ code.
+ // The SAME data, THREE access paradigms, ONE system
+ Table customerTable = client.tables().table("customers");
+
+ // 1. Key-value access for cache-like performance
+ Customer customer = customerTable.keyValueView()
+ .get(tx, Tuple.create().set("customer_id", customerId));
+
+ // 2. SQL access for complex analytics
+ ResultSet<SqlRow> analytics = client.sql().execute(tx,
+ "SELECT segment, AVG(order_value) FROM customers WHERE region = ?",
region);
+
+ // 3. Record access for type-safe operations
+ CustomerRecord record = customerTable.recordView()
+ .get(tx, new CustomerRecord(customerId));
+
+ // All three: same schema, same data, same transaction model
+
+p #[strong Eliminates:]
+ul
+ li #[strong Cache API] for cache operations
+ li Data movement during #[strong distributed joins] for analytical queries
+ li #[strong Custom mapping logic] for type-safe access
+ li #[strong Data synchronization] between cache and database
+ li #[strong Schema drift risks] across different systems
+
+p #[strong Unified advantage:] One schema, one transaction model, multiple
access paths.
+
+hr
+
+h3 Apache Ignite Architecture Preview
+
+p The ability to handle high-velocity events without multi-system overhead
requires specific technical innovations:
+ul
+ li #[strong Memory-first storage]: Event data lives in memory with optimized
access times typically under 10 microseconds for cache-resident data
+ li #[strong Collocated compute]: Processing happens where data already
exists, eliminating movement
+ li #[strong Integrated transactions]: ACID guarantees span cache, database,
and compute operations
+ li #[strong Minimal data copying]: Events process against live data through
collocated processing and direct memory access
+
+p These innovations address the compound effects that make multi-system
architectures unsuitable for high-velocity applications.
+
+hr
+
+h3 Business Impact of Architectural Evolution
+
+h3 Cost Efficiency
+ul
+ li #[strong Reduced infrastructure]: one platform instead of several
+ li #[strong Lower network costs]: eliminate inter-system bandwidth overhead
+ li #[strong Simplified operations]: fewer platforms to monitor, backup, and
scale
+
+h3 Performance Gains
+ul
+ li #[strong Microsecond latency]: eliminates network overhead
+ li #[strong Higher throughput]: more events on existing hardware
+ li #[strong Predictable scaling]: consistent performance under load
+
+h3 Developer Experience
+ul
+ li #[strong Single API]: one model for all data operations
+ li #[strong Consistent behavior]: no synchronization anomalies
+ li #[strong Faster delivery]: one integrated system to test and debug
+
+hr
+
+h3 The Architectural Evolution Decision
+
+p Every successful application reaches this point: the architecture that once
fueled growth now constrains it.
+
+p #[strong The question isn't whether you'll hit multi-system scaling limits.
It's how you'll evolve past them.]
+
+p #[strong Apache Ignite] consolidates transactions, caching, and compute into
a single, memory-first platform designed for high-velocity workloads. Instead
of managing the compound complexity of coordinating multiple systems at scale,
you consolidate core operations into a platform designed for high-velocity
applications.
+
+p Your winning architecture doesn't have to become your scaling limit. It can
evolve into the foundation for your next phase of growth.
+
+hr
+br
+|
+p #[em Return next Tuesday for Part 2, where we examine how Apache Ignite’s
memory-first architecture enables optimized event processing while maintaining
durability, forming the basis for true high-velocity performance.]
+
+
diff --git a/blog/ignite/index.html
b/blog/apache-ignite-3-architecture-part-1.html
similarity index 56%
copy from blog/ignite/index.html
copy to blog/apache-ignite-3-architecture-part-1.html
index 6c21066391..e1d2935c2d 100644
--- a/blog/ignite/index.html
+++ b/blog/apache-ignite-3-architecture-part-1.html
@@ -3,16 +3,11 @@
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0,
maximum-scale=1" />
- <title>Entries tagged [ignite]</title>
- <meta property="og:title" content="Entries tagged [ignite]" />
- <link rel="canonical" href="https://ignite.apache.org/blog"; />
- <meta property="og:type" content="article" />
- <meta property="og:url" content="https://ignite.apache.org/blog"; />
- <meta property="og:image" content="/img/og-pic.png" />
+ <title>Apache Ignite Architecture Series: Part 1 - When Multi-System
Complexity Compounds at Scale</title>
<link rel="stylesheet"
href="/js/vendor/hystmodal/hystmodal.min.css?ver=0.9" />
<link rel="stylesheet" href="/css/utils.css?ver=0.9" />
<link rel="stylesheet" href="/css/site.css?ver=0.9" />
- <link rel="stylesheet" href="/css/blog.css?ver=0.9" />
+ <link rel="stylesheet" href="../css/blog.css?ver=0.9" />
<link rel="stylesheet" href="/css/media.css?ver=0.9" media="only screen
and (max-width:1199px)" />
<link rel="icon" type="image/png" href="/img/favicon.png" />
<!-- Matomo -->
@@ -337,205 +332,347 @@
<div class="dropmenu__back"></div>
<header class="hdrfloat hdr__white jsHdrFloatBase"></header>
<div class="container blog">
- <section class="blog__header"><h1>Entries tagged [ignite]</h1></section>
+ <section class="blog__header post_page__header">
+ <a href="/blog/">← Apache Ignite Blog</a>
+ <h1>Apache Ignite Architecture Series: Part 1 - When Multi-System
Complexity Compounds at Scale</h1>
+ <p>
+ November 25, 2025 by <strong>Michael Aglietti. Share in </strong><a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/undefined";>Facebook</a><span>,
</span
+ ><a href="http://twitter.com/home?status=Apache Ignite Architecture
Series: Part 1 - When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/undefined";>Twitter</a>
+ </p>
+ </section>
<div class="blog__content">
<main class="blog_main">
<section class="blog__posts">
<article class="post">
- <div class="post__header">
- <h2><a
href="/blog/schema-design-for-distributed-systems-ai3.html"> Schema Design for
Distributed Systems: Why Data Placement Matters</a></h2>
- <div>
- November 18, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/schema-design-for-distributed-systems-ai3.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status= Schema Design for
Distributed Systems: Why Data Placement
Matters%20https://ignite.apache.org/blog/schema-design-for-distributed-systems-ai3.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content"><p>Discover how Apache Ignite 3 keeps
related data together with schema-driven colocation, cutting cross-node traffic
and making distributed queries fast, local and predictable.</p></div>
- <div class="post__footer"><a class="more"
href="/blog/schema-design-for-distributed-systems-ai3.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/getting-to-know-apache-ignite-3.html">Getting to Know Apache Ignite
3: A Schema-Driven Distributed Computing Platform</a></h2>
- <div>
- November 11, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/getting-to-know-apache-ignite-3.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Getting to Know
Apache Ignite 3: A Schema-Driven Distributed Computing
Platform%20https://ignite.apache.org/blog/getting-to-know-apache-ignite-3.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
+ <div>
<p>
- Apache Ignite 3 is a memory-first distributed SQL database
platform that consolidates transactions, analytics, and compute workloads
previously requiring separate systems. Built from the ground up, it represents
a complete
- departure from traditional caching solutions toward a
unified distributed computing platform with microsecond latencies and
collocated processing capabilities.
+ Apache Ignite shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
+ architecture removes the latency tax entirely.
</p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/getting-to-know-apache-ignite-3.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/whats-new-in-apache-ignite-3-1.html">Apache
Ignite 3.1: Performance, Multi-Language Client Support, and Production
Hardening</a></h2>
- <div>
- November 3, 2025 by Evgeniy Stanilovskiy. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-1.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 3.1:
Performance, Multi-Language Client Support, and Production
Hardening%20https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-1.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
+ <!-- end -->
<p>
- Apache Ignite 3.1 improves the three areas that matter most
when running distributed systems: performance at scale, language flexibility,
and operational visibility. The release also fixes hundreds of bugs related to
data
- corruption, race conditions, and edge cases discovered since
3.0.
+ Your high-velocity application started with smart
architectural choices. PostgreSQL for reliable transactions, Redis for fast
cache access, custom processing for specific business logic. These decisions
enabled initial
+ success and growth.
</p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/whats-new-in-apache-ignite-3-1.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/whats-new-in-apache-ignite-3-0.html">What's
New in Apache Ignite 3.0</a></h2>
- <div>
- February 24, 2025 by Stanislav Lukyanov. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=What's New in
Apache Ignite
3.0%20https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
<p>
- Apache Ignite 3.0 is the latest milestone in Apache Ignite
evolution that enhances developer experience, platform resilience, and
efficiency. In this article, we’ll explore the key new features and
improvements in Apache
- Ignite 3.0.
+ But success changes the game. Your application now processes
thousands of events per second and customers expect microsecond response times.
Real-time insights drive competitive advantage. The same architectural choices
+ that enabled growth now create performance bottlenecks that
compound with every additional event.
</p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/whats-new-in-apache-ignite-3-0.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-17-0.html">Apache Ignite
2.17 Release: What’s New</a></h2>
- <div>
- February 13, 2025 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-17-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 2.17
Release: What’s
New%20https://ignite.apache.org/blog/apache-ignite-2-17-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
+ <p><strong>At high event volumes, data movement between
systems becomes the primary performance constraint</strong>.</p>
+ <hr />
+ <h3>The Scale Reality for High-Velocity Applications</h3>
<p>
- We are happy to announce the release of <a
href="https://ignite.apache.org/";>Apache Ignite </a>2.17.0! In this latest
version, the Ignite community has introduced a range of new features and
improvements to deliver a more
- efficient, flexible, and future-proof platform. Below, we’ll
cover the key highlights that you can look forward to when upgrading to the new
release.
+ As event volume grows, architectural compromises that once
seemed reasonable at lower scale become critical bottlenecks. Consider a
financial trading platform, gaming backend, or IoT processor handling tens of
thousands of
+ operations per second.
</p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-17-0.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/apache-ignite-net-intel-cet-fix.html">Ignite on .NET 9 and Intel
CET</a></h2>
- <div>
- November 22, 2024 by Pavel Tupitsyn. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-net-intel-cet-fix.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Ignite on .NET 9
and Intel
CET%20https://ignite.apache.org/blog/apache-ignite-net-intel-cet-fix.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>Old JDK code meets new Intel security feature, JVM + CLR in
one process, and a mysterious crash.</p>
- <p><a href="https://ptupitsyn.github.io/Ignite-on-NET-9/";>Read
More...</a></p>
- </div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-16-0.html">Apache Ignite
2.16.0: Cache dumps, Calcite engine stabilization, JDK 14+ bug fixes</a></h2>
- <div>
- December 25, 2023 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-16-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.16.0: Cache dumps, Calcite engine stabilization, JDK 14+ bug
fixes%20https://ignite.apache.org/blog/apache-ignite-2-16-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- As of December 25, 2023, <a
href="https://ignite.apache.org/";>Apache Ignite </a>2.16 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/j3brc";>Important JIRA tasks </a>but
- let's briefly overview some valuable improvements.
- </p>
- <h3 id="cache-dumps">Cache dumps</h3>
- <p>
- Ignite has persistent cache <a
href="https://ignite.apache.org/docs/latest/snapshots/snapshots";>snapshots
</a>and this feature is highly appreciated by Ignite users. This release
introduces another way to make a copy of
- user data - a cache dump.
- </p>
- <p>
- The cache dump is essentially a file that contains all
entries of a cache group at the time of dump creation. Dump is consistent like
a snapshot, which means all entries that existed in the cluster at the moment
of dump
- creation will be included in the dump file. Meta information
of dumped caches and binary meta are also included in the dump.
- </p>
- <p>Main differences from cache snapshots:</p>
+ <h3>Event Processing Under Pressure</h3>
+ <p><strong>High-frequency event characteristics</strong></p>
<ul>
- <li>Supports in-memory caches that a snapshot feature does
not support.</li>
- <li>Takes up less disk space. The dump contains only the
cache entries as-is.</li>
- <li>Can be used for offline data processing.</li>
+ <li>Events arrive faster than traditional batch processing
can handle</li>
+ <li>Each event requires immediate consistency checks against
live data</li>
+ <li>Results must update multiple downstream systems
simultaneously</li>
+ <li>Network delays compound into user-visible lag</li>
+ <li><strong>Traffic spikes create systemic pressure</strong>
— traditional stacks drop connections or crash when overwhelmed</li>
</ul>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-16-0.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/apache-ignite-net-dynamic-linq.html">Dynamic LINQ performance and
usability with Ignite.NET and System.Linq.Dynamic</a></h2>
- <div>
- May 22, 2023 by Pavel Tupitsyn. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-net-dynamic-linq.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Dynamic LINQ
performance and usability with Ignite.NET and
System.Linq.Dynamic%20https://ignite.apache.org/blog/apache-ignite-net-dynamic-linq.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>Dynamically building database queries can be necessary for
some use cases, such as UI-defined filtering. This can get challenging with
LINQ frameworks like EF Core and Ignite.NET.</p>
- <p><a
href="https://ptupitsyn.github.io/Dynamic-LINQ-With-Ignite/";>Read
More...</a></p>
- </div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-13-0.html">Apache Ignite
2.13.0: new Apache Calcite-based SQL engine</a></h2>
- <div>
- April 28, 2022 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.13.0: new Apache Calcite-based SQL
engine%20https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- As of April 26, 2022, <a
href="https://ignite.apache.org/";>Apache Ignite</a> 2.13 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/x8u49";>Important JIRA tasks</a> but here
- let's briefly overview some valuable improvements.
- </p>
- <h4>This is a breaking change release: The legacy service grid
implementation was removed.</h4>
- <h3 id="new-apache-calcite-based-sql-engine">New Apache
Calcite-based SQL engine</h3>
- <p>We've implemented a new experimental SQL engine based
on Apache Calcite. Now it's possible to:</p>
+ <p><strong>The compounding effect</strong></p>
<ul>
- <li>Get rid of some <a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Motivation";>H2
limitations</a>;</li>
- <li><a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Implementationdetails";>Optimize</a>
some query execution.</li>
+ <li>At 100 events per second, network latency of 2ms adds
minimal overhead.</li>
+ <li>At 10,000 events per second, that same 2ms latency
creates a 20-second processing backlog within system boundaries.</li>
+ <li>During traffic spikes (50,000+ events per second),
traditional systems collapse entirely, dropping connections and losing data
when they're needed most.</li>
</ul>
- <p>The current H2-based engine has fundamental limitations.
For example:</p>
+ <p>The math scales against you.</p>
+ <hr />
+ <h3>When Smart Choices Become Scaling Limits</h3>
+ <p><strong>Initial Architecture, works great at lower
scale:</strong></p>
+ <pre class="mermaid">flowchart TB
+ subgraph "Event Processing"
+ Events[High-Volume Events<br/>10,000/sec]
+ end
+
+ subgraph "Multi-System Architecture"
+ Redis[(Cache<br/>Session Data<br/>2ms latency)]
+ PostgreSQL[(Relational DB<br/>Transaction Data<br/>5ms latency)]
+ Processing[Custom Processing<br/>Business Logic<br/>3ms latency]
+ end
+
+ Events --> Redis
+ Events --> PostgreSQL
+ Events --> Processing
+
+ Redis <-->|Sync Overhead| PostgreSQL
+ PostgreSQL <-->|Data Movement| Processing
+ Processing <-->|Cache Updates| Redis
+</pre>
+ <p><strong>What happens at scale</strong></p>
<ul>
- <li>some queries should be splitted into 2 phases (map
subquery and reduce subquery), but some of them cannot be effectively executed
in 2 phases.</li>
- <li>H2 is a third-party database product with not-ASF
license.</li>
- <li>The optimizer and other internal things are not supposed
to work in a distributed environment.</li>
- <li>It's hard to make Ignite-specific changes to the H2
code, patches are often declined.</li>
+ <li><strong>Network-latency tax:</strong> Every system hop
adds milliseconds that compound</li>
+ <li><strong>Synchronization delays:</strong> Keeping systems
consistent creates processing queues</li>
+ <li><strong>Memory overhead:</strong> Each system caches the
same data in different formats</li>
+ <li><strong>Consistency windows:</strong> Brief periods
where systems show different data states</li>
</ul>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-13-0.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-12-0.html">Apache Ignite
2.12.0: CDC, Index Query API, Vulnerabilities Fixes</a></h2>
- <div>
- January 14, 2022 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-12-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.12.0: CDC, Index Query API, Vulnerabilities
Fixes%20https://ignite.apache.org/blog/apache-ignite-2-12-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
+ <hr />
+ <h3>The Hidden Cost of Multi-System Success</h3>
+ <p><strong>Data Movement Overhead:</strong></p>
+ <p>Your events don't just need processing, they need
processing that maintains consistency across all systems.</p>
+ <p>Each event triggers:</p>
+ <ul>
+ <li><strong>Cache lookup (Redis):</strong> ≈ 0.5 ms network
+ processing</li>
+ <li><strong>Transaction validation (PostgreSQL):</strong> ≈
2 ms network + disk I/O</li>
+ <li><strong>Business-logic execution (Custom):</strong> ≈
1ms processing + data marshalling</li>
+ <li><strong>Result synchronization (across
systems):</strong> ≈ 3 ms coordination overhead</li>
+ </ul>
+ <p><strong>Minimum per-event cost ≈ 7 ms before business
logic.</strong></p>
+ <p>At 10,000 events/s, you’d need 70 seconds of processing
capacity just <strong>for data movement</strong> per real-time second!</p>
+ <hr />
+ <h3>The Performance Gap That Grows With Success</h3>
+ <h3>Why Traditional Options Fail</h3>
+ <p><strong>Option 1: Scale out each system</strong></p>
+ <ul>
+ <li><strong>Strategy</strong>: Add cache clusters, database
replicas, processing nodes</li>
+ <li><strong>Result</strong>: More systems to coordinate,
exponentially more complexity</li>
+ <li><strong>Reality</strong>: Network overhead grows faster
than processing capacity</li>
+ </ul>
+ <p><strong>Option 2: Custom optimization</strong></p>
+ <ul>
+ <li><strong>Strategy</strong>: Build application-layer
caching, custom consistency protocols</li>
+ <li><strong>Result</strong>: Engineering team maintains
complex, system-specific optimizations</li>
+ <li><strong>Reality</strong>: Solutions don't generalize;
each optimization creates technical debt</li>
+ </ul>
+ <p><strong>Option 3: Accept compromises</strong></p>
+ <ul>
+ <li><strong>Strategy</strong>: Use async processing,
eventual consistency, and accept delayed insights</li>
+ <li><strong>Result</strong>: Business requirements
compromised to fit architectural limitations</li>
+ <li><strong>Reality</strong>: Competitive disadvantage as
customer expectations grow</li>
+ </ul>
+ <hr />
+ <h3>The Critical Performance Gap</h3>
+ <table style="borderlicollapse: collapse; margin: 20px 0;
width: 100%">
+ <thead>
+ <tr>
+ <th style="border: 1px solid #ddd; padding: 12px;
background-color: #f5f5f5; text-align: left">Component</th>
+ <th style="border: 1px solid #ddd; padding: 12px;
background-color: #f5f5f5; text-align: left">Optimized for</th>
+ <th style="border: 1px solid #ddd; padding: 12px;
background-color: #f5f5f5; text-align: left">Typical Latency</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td style="border: 1px solid #ddd; padding:
12px">Database</td>
+ <td style="border: 1px solid #ddd; padding: 12px">ACID
transactions</td>
+ <td style="border: 1px solid #ddd; padding:
12px">Milliseconds</td>
+ </tr>
+ <tr>
+ <td style="border: 1px solid #ddd; padding:
12px">Cache</td>
+ <td style="border: 1px solid #ddd; padding: 12px">Access
speed</td>
+ <td style="border: 1px solid #ddd; padding:
12px">Microseconds</td>
+ </tr>
+ <tr>
+ <td style="border: 1px solid #ddd; padding:
12px">Compute</td>
+ <td style="border: 1px solid #ddd; padding:
12px">Throughput</td>
+ <td style="border: 1px solid #ddd; padding:
12px">Minutes – hours</td>
+ </tr>
+ </tbody>
+ </table>
+ <p>Applications needing <strong>microsecond insights</strong>
on <strong>millisecond transactions</strong> have no good options at scale in
traditional architectures.</p>
<p>
- As of January 14, 2022, <a
href="https://ignite.apache.org/";>Apache Ignite</a> 2.12 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/0zyi2";>Important JIRA tasks</a> but here
- let’s briefly overview some valuable improvements.
+ During traffic spikes, traditional architectures either drop
connections (data loss) or degrade performance (missed SLAs). High-velocity
applications need intelligent flow control that guarantees stability under
pressure
+ while preserving data integrity.
</p>
- <h3 id="vulnerability-updates">Vulnerability Updates</h3>
+ <hr />
+ <h3>Event Processing at Scale</h3>
+ <p><strong>Here's what traditional multi-system event
processing costs:</strong></p>
+ <pre><code>// Traditional multi-system event processing
+long startTime = System.nanoTime();
+
+// 1. Cache lookup for session data
+String sessionData = redisClient.get("session:" + eventId); // ~500μs network
+if (sessionData == null) {
+ sessionData = postgresDB.query("SELECT * FROM sessions WHERE id = ?",
eventId); // ~2ms fallback
+ redisClient.setex("session:" + eventId, 300, sessionData); // ~300μs
cache update
+}
+
+// 2. Transaction processing
+postgresDB.executeTransaction(tx -> { // ~2-5ms transaction
+ tx.execute("INSERT INTO events VALUES (?, ?, ?)", eventId, userId,
eventData);
+ tx.execute("UPDATE user_stats SET event_count = event_count + 1 WHERE
user_id = ?", userId);
+});
+
+// 3. Custom processing with consistency coordination
+ProcessingResult result = customProcessor.process(eventData, sessionData); //
~1ms processing
+redisClient.setex("result:" + eventId, 600, result); // ~300μs result caching
+
+// 4. Synchronization across systems
+ensureConsistency(eventId, sessionData, result); // ~2-3ms coordination
+
+long totalTime = System.nanoTime() - startTime;
+// Total: 6-12ms per event (not including queuing delays)
+
+</code></pre>
+ <p><strong>Compound Effect at Scale:</strong></p>
+ <table style="border-collapse: collapse; margin: 20px 0;
width: 100%">
+ <thead>
+ <tr>
+ <th style="border: 1px solid #ddd; padding: 12px;
background-color: #f5f5f5; text-align: left">Rate</th>
+ <th style="border: 1px solid #ddd; padding: 12px;
background-color: #f5f5f5; text-align: left">Required processing time / s</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td style="border: 1px solid #ddd; padding: 12px">1,000
events / s</td>
+ <td style="border: 1px solid #ddd; padding: 12px">6–12
s</td>
+ </tr>
+ <tr>
+ <td style="border: 1px solid #ddd; padding: 12px">5,000
events / s</td>
+ <td style="border: 1px solid #ddd; padding: 12px">30–60
s</td>
+ </tr>
+ <tr>
+ <td style="border: 1px solid #ddd; padding: 12px">10,000
events / s</td>
+ <td style="border: 1px solid #ddd; padding: 12px">60–120
s</td>
+ </tr>
+ </tbody>
+ </table>
+ <p><strong>The math doesn’t work:</strong> parallelism helps,
but coordination overhead grows exponentially with system count.</p>
+ <hr />
+ <h3>Real-World Breaking Points</h3>
+ <ul>
+ <li><strong>Financial services</strong>: Trading platforms
hitting 10,000+ trades/second discover that compliance reporting delays impact
trading decisions.</li>
+ <li><strong>Gaming platforms</strong>: Multiplayer backends
processing user actions find that leaderboard updates lag behind gameplay
events.</li>
+ <li><strong>IoT analytics</strong>: Manufacturing systems
processing sensor data realize that anomaly detection arrives too late for
preventive action.</li>
+ </ul>
+ <hr />
+ <h3>The Apache Ignite Alternative</h3>
+ <h3>Eliminating Multi-System Overhead</h3>
+ <pre class="mermaid">flowchart TB
+ subgraph "Event Processing"
+ Events[High-Volume Events<br/>10,000/sec]
+ end
+
+ subgraph "Apache Ignite Platform"
+ subgraph "Collocated Processing"
+ Memory[Memory-First Storage<br/>Optimized Access Times]
+ Transactions[MVCC Transactions<br/>ACID Guarantees]
+ Compute[Event Processing<br/>Where Data Lives]
+ end
+ end
+
+ Events --> Memory
+ Memory --> Transactions
+ Transactions --> Compute
+
+ Memory <-->|Minimal Copying| Transactions
+ Transactions <-->|Collocated| Compute
+ Compute <-->|Direct Access| Memory
+</pre>
+ <p><strong>Key difference:</strong> events process
<strong>where the data lives</strong>, eliminating inter-system latency.</p>
+ <hr />
+ <h3>Apache Ignite Performance Reality Check</h3>
+ <p><strong>Here's the same event processing with integrated
architecture:</strong></p>
+ <pre><code>// Apache Ignite integrated event processing
+try (IgniteClient client =
IgniteClient.builder().addresses("cluster:10800").build()) {
+ // Single integrated transaction spanning cache, database, and compute
+ client.transactions().runInTransaction(tx -> {
+ // 1. Access session data (in memory, no network overhead)
+ Session session = client.tables().table("sessions")
+ .keyValueView().get(tx, Tuple.create().set("id", eventId));
+
+ // 2. Process event with ACID guarantees (same memory space)
+ client.sql().execute(tx, "INSERT INTO events VALUES (?, ?, ?)",
+ eventId, userId, eventData);
+
+ // 3. Execute processing collocated with data
+ ProcessingResult result = client.compute().execute(
+ JobTarget.colocated("events", Tuple.create().set("id", eventId)),
+ EventProcessor.class, eventData);
+
+ // 4. Update derived data (same transaction, guaranteed consistency)
+ client.sql().execute(tx, "UPDATE user_stats SET event_count =
event_count + 1 WHERE user_id = ?", userId);
+
+ return result;
+ });
+}
+// Result: microsecond-range event processing through integrated architecture
+</code></pre>
+ <p>Processing 10,000 events/s is achievable with integrated
architecture eliminating network overhead.</p>
+ <hr />
+ <h3>The Unified Data-Access Advantage</h3>
+ <p><strong>Here's what eliminates the need for separate
systems:</strong></p>
+ <pre><code>// The SAME data, THREE access paradigms, ONE system
+Table customerTable = client.tables().table("customers");
+
+// 1. Key-value access for cache-like performance
+Customer customer = customerTable.keyValueView()
+ .get(tx, Tuple.create().set("customer_id", customerId));
+
+// 2. SQL access for complex analytics
+ResultSet<SqlRow> analytics = client.sql().execute(tx,
+ "SELECT segment, AVG(order_value) FROM customers WHERE region = ?",
region);
+
+// 3. Record access for type-safe operations
+CustomerRecord record = customerTable.recordView()
+ .get(tx, new CustomerRecord(customerId));
+
+// All three: same schema, same data, same transaction model
+</code></pre>
+ <p><strong>Eliminates:</strong></p>
+ <ul>
+ <li><strong>Cache API</strong> for cache operations</li>
+ <li>Data movement during <strong>distributed joins</strong>
for analytical queries</li>
+ <li><strong>Custom mapping logic</strong> for type-safe
access</li>
+ <li><strong>Data synchronization</strong> between cache and
database</li>
+ <li><strong>Schema drift risks</strong> across different
systems</li>
+ </ul>
+ <p><strong>Unified advantage:</strong> One schema, one
transaction model, multiple access paths.</p>
+ <hr />
+ <h3>Apache Ignite Architecture Preview</h3>
+ <p>The ability to handle high-velocity events without
multi-system overhead requires specific technical innovations:</p>
+ <ul>
+ <li><strong>Memory-first storage</strong>: Event data lives
in memory with optimized access times typically under 10 microseconds for
cache-resident data</li>
+ <li><strong>Collocated compute</strong>: Processing happens
where data already exists, eliminating movement</li>
+ <li><strong>Integrated transactions</strong>: ACID
guarantees span cache, database, and compute operations</li>
+ <li><strong>Minimal data copying</strong>: Events process
against live data through collocated processing and direct memory access</li>
+ </ul>
+ <p>These innovations address the compound effects that make
multi-system architectures unsuitable for high-velocity applications.</p>
+ <hr />
+ <h3>Business Impact of Architectural Evolution</h3>
+ <h3>Cost Efficiency</h3>
+ <ul>
+ <li><strong>Reduced infrastructure</strong>: one platform
instead of several</li>
+ <li><strong>Lower network costs</strong>: eliminate
inter-system bandwidth overhead</li>
+ <li><strong>Simplified operations</strong>: fewer platforms
to monitor, backup, and scale</li>
+ </ul>
+ <h3>Performance Gains</h3>
+ <ul>
+ <li><strong>Microsecond latency</strong>: eliminates network
overhead</li>
+ <li><strong>Higher throughput</strong>: more events on
existing hardware</li>
+ <li><strong>Predictable scaling</strong>: consistent
performance under load</li>
+ </ul>
+ <h3>Developer Experience</h3>
+ <ul>
+ <li><strong>Single API</strong>: one model for all data
operations</li>
+ <li><strong>Consistent behavior</strong>: no synchronization
anomalies</li>
+ <li><strong>Faster delivery</strong>: one integrated system
to test and debug</li>
+ </ul>
+ <hr />
+ <h3>The Architectural Evolution Decision</h3>
+ <p>Every successful application reaches this point: the
architecture that once fueled growth now constrains it.</p>
+ <p><strong>The question isn't whether you'll hit multi-system
scaling limits. It's how you'll evolve past them.</strong></p>
<p>
- The Apache Ignite versions lower than 2.11.1 are vulnerable
to <a
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a>
which is related to the <code>ignite-log4j2</code> module usage.
+ <strong>Apache Ignite</strong> consolidates transactions,
caching, and compute into a single, memory-first platform designed for
high-velocity workloads. Instead of managing the compound complexity of
coordinating multiple
+ systems at scale, you consolidate core operations into a
platform designed for high-velocity applications.
</p>
- <p>The release also fixes 10+ CVE’s of various modules.
See <a
href="https://ignite.apache.org/releases/ignite2/2.12.0/release_notes.html";>release
notes</a> for more details.</p>
- <h3 id="change-data-capture">Change Data Capture</h3>
+ <p>Your winning architecture doesn't have to become your
scaling limit. It can evolve into the foundation for your next phase of
growth.</p>
+ <hr />
+ <br />
<p>
- Change Data Capture (<a
href="https://en.wikipedia.org/wiki/Change_data_capture";>CDC</a>) is a data
processing pattern used to asynchronously receive entries that have been
changed on the local node so that action can be
- taken using the changed entry.
+ <em>Return next Tuesday for Part 2, where we examine how
Apache Ignite’s memory-first architecture enables optimized event processing
while maintaining durability, forming the basis for true high-velocity
performance.</em>
</p>
</div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-12-0.html">↓ Read all</a></div>
</article>
- </section>
- <section class="blog__footer">
- <ul class="pagination">
- <li><a class="current" href="/blog/ignite">1</a></li>
- <li><a class="item" href="/blog/ignite/1/">2</a></li>
- <li><a class="item" href="/blog/ignite/2/">3</a></li>
- </ul>
+ <section class="blog__footer">
+ <ul class="pagination post_page">
+ <li><a href="/blog/apache">apache</a></li>
+ <li><a href="/blog/ignite">ignite</a></li>
+ </ul>
+ </section>
</section>
</main>
<aside class="blog__sidebar">
@@ -640,6 +777,7 @@
></a>
<script src="/js/vendor/hystmodal/hystmodal.min.js"></script>
<script src="/js/vendor/smoothscroll.js"></script>
+ <script src="/js/vendor/mermaid/mermaid.min.js"></script>
<script src="/js/main.js?ver=0.9"></script>
</body>
</html>
diff --git a/blog/apache/index.html b/blog/apache/index.html
index 4f4fe9c3c2..8aaa795479 100644
--- a/blog/apache/index.html
+++ b/blog/apache/index.html
@@ -341,6 +341,22 @@
<div class="blog__content">
<main class="blog_main">
<section class="blog__posts">
+ <article class="post">
+ <div class="post__header">
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale</a></h2>
+ <div>
+ November 25, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Facebook</a><span>,
</span
+ ><a href="http://twitter.com/home?status=Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
+ </div>
+ </div>
+ <div class="post__content">
+ <p>
+ Apache Ignite 3 shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
+ architecture removes the latency tax entirely.
+ </p>
+ </div>
+ <div class="post__footer"><a class="more"
href="/blog/apache-ignite-3-architecture-part-1.html">↓ Read all</a></div>
+ </article>
<article class="post">
<div class="post__header">
<h2><a
href="/blog/schema-design-for-distributed-systems-ai3.html"> Schema Design for
Distributed Systems: Why Data Placement Matters</a></h2>
@@ -525,28 +541,6 @@
</div>
<div class="post__footer"><a class="more"
href="/blog/apache-ignite-essentials-series-for.html">↓ Read all</a></div>
</article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-3-more.html">Apache Ignite
2.3 - More SQL and Persistence Capabilities</a></h2>
- <div>
- November 1, 2017 by Denis Magda. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-3-more.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 2.3 -
More SQL and Persistence
Capabilities%20https://ignite.apache.org/blog/apache-ignite-2-3-more.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>Putting aside the regular bug fixes and performance
optimizations, the Apache Ignite 2.3 release brings new SQL capabilities and
Ignite persistence improvements that are worth mentioning.</p>
- <p></p>
- <h3>SQL</h3>
- <p></p>
- <p>Let's start with SQL first.</p>
- <p>Apache Ignite users have consistently told us that despite
all of Ignite’s SQL capabilities, it’s been at times challenging
trying to figure out how to start using Ignite as an SQL database.</p>
- <p>
- This was mostly caused by scattered documentation pages,
lack of “getting started” guides and tutorials. We’ve
remedied this oversight! All related SQL knowledge has been curated in a
- <a href="https://apacheignite-sql.readme.io/docs";
target="_blank">single documentation domain</a>.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-3-more.html">↓ Read all</a></div>
- </article>
</section>
<section class="blog__footer">
<ul class="pagination">
@@ -657,6 +651,7 @@
></a>
<script src="/js/vendor/hystmodal/hystmodal.min.js"></script>
<script src="/js/vendor/smoothscroll.js"></script>
+ <script src="/js/vendor/mermaid/mermaid.min.js"></script>
<script src="/js/main.js?ver=0.9"></script>
</body>
</html>
diff --git a/blog/ignite/index.html b/blog/ignite/index.html
index 6c21066391..b632ccfde4 100644
--- a/blog/ignite/index.html
+++ b/blog/ignite/index.html
@@ -341,6 +341,22 @@
<div class="blog__content">
<main class="blog_main">
<section class="blog__posts">
+ <article class="post">
+ <div class="post__header">
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale</a></h2>
+ <div>
+ November 25, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Facebook</a><span>,
</span
+ ><a href="http://twitter.com/home?status=Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
+ </div>
+ </div>
+ <div class="post__content">
+ <p>
+ Apache Ignite 3 shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
+ architecture removes the latency tax entirely.
+ </p>
+ </div>
+ <div class="post__footer"><a class="more"
href="/blog/apache-ignite-3-architecture-part-1.html">↓ Read all</a></div>
+ </article>
<article class="post">
<div class="post__header">
<h2><a
href="/blog/schema-design-for-distributed-systems-ai3.html"> Schema Design for
Distributed Systems: Why Data Placement Matters</a></h2>
@@ -503,32 +519,6 @@
</div>
<div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-13-0.html">↓ Read all</a></div>
</article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-12-0.html">Apache Ignite
2.12.0: CDC, Index Query API, Vulnerabilities Fixes</a></h2>
- <div>
- January 14, 2022 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-12-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.12.0: CDC, Index Query API, Vulnerabilities
Fixes%20https://ignite.apache.org/blog/apache-ignite-2-12-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- As of January 14, 2022, <a
href="https://ignite.apache.org/";>Apache Ignite</a> 2.12 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/0zyi2";>Important JIRA tasks</a> but here
- let’s briefly overview some valuable improvements.
- </p>
- <h3 id="vulnerability-updates">Vulnerability Updates</h3>
- <p>
- The Apache Ignite versions lower than 2.11.1 are vulnerable
to <a
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a>
which is related to the <code>ignite-log4j2</code> module usage.
- </p>
- <p>The release also fixes 10+ CVE’s of various modules.
See <a
href="https://ignite.apache.org/releases/ignite2/2.12.0/release_notes.html";>release
notes</a> for more details.</p>
- <h3 id="change-data-capture">Change Data Capture</h3>
- <p>
- Change Data Capture (<a
href="https://en.wikipedia.org/wiki/Change_data_capture";>CDC</a>) is a data
processing pattern used to asynchronously receive entries that have been
changed on the local node so that action can be
- taken using the changed entry.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-12-0.html">↓ Read all</a></div>
- </article>
</section>
<section class="blog__footer">
<ul class="pagination">
@@ -640,6 +630,7 @@
></a>
<script src="/js/vendor/hystmodal/hystmodal.min.js"></script>
<script src="/js/vendor/smoothscroll.js"></script>
+ <script src="/js/vendor/mermaid/mermaid.min.js"></script>
<script src="/js/main.js?ver=0.9"></script>
</body>
</html>
diff --git a/blog/index.html b/blog/index.html
index 0df8df2c2e..99128007e9 100644
--- a/blog/index.html
+++ b/blog/index.html
@@ -341,6 +341,22 @@
<div class="blog__content">
<main class="blog_main">
<section class="blog__posts">
+ <article class="post">
+ <div class="post__header">
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale</a></h2>
+ <div>
+ November 25, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Facebook</a><span>,
</span
+ ><a href="http://twitter.com/home?status=Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
+ </div>
+ </div>
+ <div class="post__content">
+ <p>
+ Apache Ignite 3 shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
+ architecture removes the latency tax entirely.
+ </p>
+ </div>
+ <div class="post__footer"><a class="more"
href="/blog/apache-ignite-3-architecture-part-1.html">↓ Read all</a></div>
+ </article>
<article class="post">
<div class="post__header">
<h2><a
href="/blog/schema-design-for-distributed-systems-ai3.html"> Schema Design for
Distributed Systems: Why Data Placement Matters</a></h2>
@@ -503,32 +519,6 @@
</div>
<div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-13-0.html">↓ Read all</a></div>
</article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-12-0.html">Apache Ignite
2.12.0: CDC, Index Query API, Vulnerabilities Fixes</a></h2>
- <div>
- January 14, 2022 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-12-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.12.0: CDC, Index Query API, Vulnerabilities
Fixes%20https://ignite.apache.org/blog/apache-ignite-2-12-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- As of January 14, 2022, <a
href="https://ignite.apache.org/";>Apache Ignite</a> 2.12 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/0zyi2";>Important JIRA tasks</a> but here
- let’s briefly overview some valuable improvements.
- </p>
- <h3 id="vulnerability-updates">Vulnerability Updates</h3>
- <p>
- The Apache Ignite versions lower than 2.11.1 are vulnerable
to <a
href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832";>CVE-2021-44832</a>
which is related to the <code>ignite-log4j2</code> module usage.
- </p>
- <p>The release also fixes 10+ CVE’s of various modules.
See <a
href="https://ignite.apache.org/releases/ignite2/2.12.0/release_notes.html";>release
notes</a> for more details.</p>
- <h3 id="change-data-capture">Change Data Capture</h3>
- <p>
- Change Data Capture (<a
href="https://en.wikipedia.org/wiki/Change_data_capture";>CDC</a>) is a data
processing pattern used to asynchronously receive entries that have been
changed on the local node so that action can be
- taken using the changed entry.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-12-0.html">↓ Read all</a></div>
- </article>
</section>
<section class="blog__footer">
<ul class="pagination">
@@ -640,6 +630,7 @@
></a>
<script src="/js/vendor/hystmodal/hystmodal.min.js"></script>
<script src="/js/vendor/smoothscroll.js"></script>
+ <script src="/js/vendor/mermaid/mermaid.min.js"></script>
<script src="/js/main.js?ver=0.9"></script>
</body>
</html>
