{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"disequilibrium_leverage_and_dissipation_management__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["hot shard flash crowd shadow split copy on read migration","hot prefix workload-driven shard splitting lazy copy reads"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["\"copy-on-read\" data migration database","\"on-demand\" data migration key value store reads","lazy data migration triggered by reads distributed storage"],"source_ids":["SRC2","SRC3"],"no_result_note":null},"products_practices_and_standards":{"queries":["site:aws.amazon.com DynamoDB split for heat adaptive capacity hot partition","site:mongodb.com/docs reshard collection cloning oplog abort"],"source_ids":["SRC1","SRC4"],"no_result_note":null},"component_combination":{"queries":["database hot partition copy reads destination on demand migration Fulva Rocksteady","hot keys online repartitioning live requests data migration","shadow traffic duplicate reads automatic abort latency threshold data migration"],"source_ids":["SRC1","SRC2","SRC3","SRC4"],"no_result_note":"No retained source disclosed the full combination of hot traffic selecting a candidate split, sampled reads lazily copying and verifying records, an explicit duplicate-work budget, stress-responsive damping, automatic threshold decoupling, disposable shadow state, and separately authorized routing promotion."}},"sources":[{"source_id":"SRC1","title":"Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance (Part 2: Querying)","publisher":"Amazon Web Services","url":"https://aws.amazon.com/blogs/database/part-2-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["A sustained concentration of reads can make one physical partition the throughput bottleneck.","DynamoDB detects a hot partition and can split it into two partitions.","The split point is chosen from recent traffic patterns to spread observed heat rather than merely bisecting the data.","Split-for-heat has workload-dependent limits and can cause a temporary query-rate dip or brief errors during cutover."]},{"source_id":"SRC2","title":"Fulva: Efficient Live Migration for In-Memory Key-Value Stores with Zero Downtime","publisher":"IEEE Computer Society","url":"https://hub.hku.hk/handle/10722/290707","source_type":"PRIMARY_RESEARCH","claims_supported":["Live migration moves key-value tuples and requests from an overloaded source to an idle destination while serving clients.","Earlier destination-driven migration represented by RockSteady pulls not-yet-present tuples from the source on demand when destination reads require them.","Fulva instead tracks migration progress, routes reads of migrated tuples to the destination, and sends reads of unmigrated tuples to both machines.","The paper treats latency, throughput, bandwidth, downtime, and linearizability as migration concerns."]},{"source_id":"SRC3","title":"In-Memory Key-Value Store Live Migration with NetMigrate","publisher":"USENIX Association","url":"https://www.usenix.org/conference/fast24/presentation/zhu","source_type":"PRIMARY_RESEARCH","claims_supported":["Dynamic workload changes motivate frequent key-value shard migration for load balancing and elasticity.","NetMigrate monitors migration at fine granularity and directs live client queries according to migration state.","The system explicitly seeks zero service interruption and minimal migration performance impact.","NetMigrate eliminates source-to-destination on-demand pulls, confirming that request-coupled transfer is known prior art but has recognized overhead."]},{"source_id":"SRC4","title":"reshardCollection (database command)","publisher":"MongoDB, Inc.","url":"https://www.mongodb.com/docs/manual/reference/command/reshardcollection/","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Online resharding constructs temporary recipient collections, clones donor data, applies later oplog changes, reaches consistency, and then commits the new arrangement.","The operation can be aborted before the commit phase but not after commitment begins.","Commit can block writes and raise application latency, making migration resource and cutover costs operationally visible.","MongoDB performs systematic cloning and catch-up rather than hot-read-selected lazy population."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"Hot-partition overload, idle capacity elsewhere, workload-driven splitting, and the performance costs of live shard migration are directly visible. However, the premise that a flash-crowd trace is representative enough to define a useful durable split is not established, and DynamoDB already demonstrates that sustained live traffic can automatically determine a traffic-aware split without the proposed shadow-read channel.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"closest_prior_art":[{"name":"DynamoDB adaptive capacity and split for heat","source_ids":["SRC1"],"overlap":"Detects sustained partition heat, uses recent traffic to choose a noncentral split point, and turns workload skew into a changed physical partition layout.","remaining_difference":"The source does not describe sampling live reads as per-record lazy copy-and-verification operations in a disposable candidate namespace, accounting for that duplicate work under a fixed budget, or requiring separate reviewed promotion."},{"name":"RockSteady-style on-demand pulling and Fulva cooperative live migration","source_ids":["SRC2"],"overlap":"Uses live requests during key-value migration; destination-driven prior art pulls records from the source when requests need unmigrated tuples, while Fulva tracks tuple migration state and duplicates reads to source and destination when necessary.","remaining_difference":"Migration already has a selected source and destination; the hot-read gradient is not disclosed as simultaneously defining a new split boundary, limiting which requests perform construction, and validating a shadow routing map under automatic stress-triggered decoupling."},{"name":"NetMigrate","source_ids":["SRC3"],"overlap":"Migrates key-value shards in response to dynamic workloads, monitors fine-grained migration state, and routes client queries to the appropriate source or destination while minimizing disruption.","remaining_difference":"It assumes an external reconfiguration plan and deliberately avoids on-demand record pulling, rather than exploiting a sampled hot flow as the copy-and-verify work channel."},{"name":"MongoDB online resharding","source_ids":["SRC4"],"overlap":"Builds a temporary destination layout through clone-and-catch-up phases, monitors a staged process, permits abort before commitment, and changes authoritative placement only at commit.","remaining_difference":"It systematically clones all documents owned under the new key rather than lazily constructing a hot working set from admitted reads, and it does not disclose the proposed dissipation ledger or source-stress-responsive sampling."}],"prior_art_disposition":"ADJACENT_PRIOR_ART","contrastive_claim_remaining":"Against traffic-derived automatic splitting, request-aware live migration, on-demand tuple pulling, and staged clone-and-commit resharding, the remaining falsifiable claim is that an equal-cost, rate-limited hot-read channel can simultaneously select records, populate their candidate destinations, and verify candidate routing with greater promotable coverage or validation yield than non-workload-prioritized copying before predefined source-headroom, latency, byte, mismatch, or queue thresholds force decoupling.","contrastive_claim_falsifier":"The contrast is falsified if trace replay shows no greater promotable coverage or routing-verification yield than an equal-cost random or sequential copy schedule; if required cold records make the partial shadow state unsafe to promote; if duplicate work breaches a stop threshold first; or if the resulting split increases imbalance or resource use on a held-out ordinary-workload trace.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered direct wording, copy-on-read and on-demand migration terminology, hot-key product behavior, live-migration research, online resharding practice, and component combinations. Exactly four opened sources span AWS, IEEE, USENIX, and MongoDB and include primary research and official or first-party material.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"The core operational problem—localized shard overload plus costly live redistribution—is visible, although the proposed surge-representativeness premise remains unverified and is therefore only partly supported.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"Broad workload-driven splitting and request-coupled migration are established, but the remaining equal-budget claim about sampled hot reads jointly constructing and verifying a nonauthoritative candidate split is distinguishable and quantitatively falsifiable.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"bounded_next_test":{"status":"PASS","rationale":"One access-controlled hotspot trace can be replayed offline against no-migration, equal-cost random or sequential copying, and rate-limited hot-flow policies. Coverage, verification yield, bytes, duplicate reads, modeled queue headroom, stop activations, and held-out workload balance provide bounded endpoints without production mutation.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The authorized first test is read-only, trace-bounded, and offline. The production routing map and records remain unchanged; trace access controls and retention limits are still required. Staged temporary-state and precommit-abort practices show that reversible evaluation is technically plausible, with any live pilot or promotion requiring separate authority.","source_ids":["SRC4"]}},"screen_survival":true,"world_novelty_boundary":"This four-source public-web screen establishes only coarse researchability and adjacent prior art. It does not establish world novelty, patentability, market size, expert acceptance, or realized value. Additional patent searches, older RockSteady literature, vendor-internal shard controllers, migration implementations, and broader systems research could substantially narrow or eliminate the remaining contrast."}