A courts clerk system sees extreme docket check-in write spikes every morning calendar open. Which specialized table feature should the team use for those bursty transactional inserts?
Select an answer to reveal the explanation.
Short Explanation
Morning calendar open can feel like a stampede at the clerk’s window—in-memory OLTP is the express lane built for that write burst. You can keep check-ins snappy with memory-optimized tables, rather than sending them to cold blob archives or analytical columnstore archives.
Full Explanation
Morning docket check-in is a classic bursty transactional write pattern: many clerks insert or update case-presence rows in a short window when calendars open. In-memory OLTP, using memory-optimized tables and related engine features, is built for high-throughput transactional inserts with latch-free structures and reduced locking contention, directly addressing these municipal write spikes without redesigning the courts application as an analytical system. An external table over cold blob archives is for querying remote files, not absorbing peak OLTP writes into the live docket. A columnstore-only archive that is never updated during the day targets analytical compression and read scans; it has the wrong update model for morning check-ins. A graph edge table linking judges to courtrooms models relationships; without a memory-optimized engine, it does not substitute for one when insert throughput is the bottleneck. Exam caveat: in-memory OLTP has durability, sizing, and feature constraints, such as which indexes and constraints are supported; use it for the hot transactional subset, not as a blanket replacement for every courts table. Practical check: under a synthetic morning spike, compare latch/wait statistics and insert throughput on a memory-optimized check-in table with a conventional disk-based table of the same logical schema, and confirm recovery settings meet the court’s RPO.