What changes when your graph has to answer in real time
Memgraph and similar in-memory, streaming graph databases change the Scrum conversation in one specific way: latency itself becomes an acceptance criterion, not a performance concern to revisit later. This module opens by contrasting the batch mindset most graph teams inherit, run a query overnight, check the result in the morning, with a real-time mindset where a feature is only done if it answers within a millisecond budget under live streaming load. Backlog items that do not state a latency target are treated as incomplete, the same way a backlog item with no acceptance criteria at all would be incomplete in any other domain.
A large part of the module covers streaming ingestion as a first-class design constraint during refinement. Unlike a static graph loaded once, a Memgraph deployment is continuously updated by incoming events, and the module teaches teams to ask, during refinement rather than during an incident, what happens to a query's correctness and speed while the graph underneath it is actively changing. Scenarios include a Sprint where a feature that worked perfectly in testing degrades under live streaming write load, and a Sprint Review where a stakeholder needs to see the system respond under simulated real traffic, not a static snapshot, before they will trust the Increment.
The module closes on capacity planning and Definition of Done criteria tuned for real-time graph work: memory budget per node and relationship type, tested behaviour under concurrent read and write load, and a documented latency service-level objective that the team actually measures against, rather than an aspirational number nobody checks after the Sprint Review ends.
Mistakes teams make with this material
Treating speed as a nice-to-have to be optimized later, when for a real-time graph system the millisecond response time is the actual acceptance criterion, not an afterthought.
Validating a feature against a graph that is not receiving live writes, then discovering in production that concurrent streaming updates change both correctness and latency.
Adding node and relationship types without tracking their in-memory footprint, since an in-memory graph database has a hard capacity ceiling that batch-oriented graph systems do not face the same way.
Showing a fast response at Sprint Review under artificially quiet conditions, without also showing the same query under realistic concurrent streaming write volume.
Questions people ask
Why does latency belong in the Definition of Done for a real-time graph feature?
Because for an in-memory, streaming graph system, a correct answer that arrives too late is functionally a wrong answer. If the team does not test and agree on a latency budget as part of done, the Increment has not actually met the need it was built for.
How should a team estimate work on a continuously updating graph?
By explicitly testing the feature under simulated concurrent write load during the Sprint, not only against a static snapshot. Refinement should ask what happens to correctness and speed while the graph is actively changing underneath the query.
What capacity planning belongs in Sprint Planning for Memgraph work?
A running estimate of memory footprint per node and relationship type, since an in-memory graph has a hard ceiling that a disk-based system does not. Adding schema elements without tracking this is how a team runs out of capacity mid-Sprint with no warning.
What should a Sprint Review for a real-time graph feature actually demonstrate?
The feature responding correctly under realistic concurrent load and streaming writes, not a quiet, artificially calm demo environment. Anything less does not give stakeholders real information about whether the Increment will hold up in production.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Which is the strongest shape for a Memgraph PBI?
- 'Make fraud detection real-time'
- 'Consume the logins Kafka topic at 5k events/sec, upsert (:User)-[:LOGGED_IN_FROM]->(:Device) within 500 ms, answer shared-device queries at p95 under 80 ms'
- 'Make it faster'
- 'Add a live dashboard'
A real-time graph PBI names the stream, event rate, mutation, freshness SLO, and query latency. That is what makes the estimate honest.