In the previous page, we developed a framework for selecting data structures based on the operations a problem requires. But operations tell only part of the story. Real systems operate under constraints—limits on resources, requirements for behavior, and characteristics that must be preserved.

Constraints act as powerful filters. A structure that seems perfect for your operation profile may be eliminated instantly when you consider memory limits, latency requirements, or the need for immutability in a concurrent system.

This page examines the three most important constraint categories:

1. Time constraints — How fast must operations complete?
2. Space constraints — How much memory can you use?
3. Mutability constraints — Does data change, and how?

Understanding these constraints—and their interactions—transforms you from someone who knows data structures to someone who can apply them effectively in production systems.

Every production system has time requirements, whether explicit (service level agreements) or implicit (user experience expectations). These requirements translate directly into complexity bounds for your data structure operations.

From latency budget to complexity requirement:

Let's work through the analysis. Suppose you're building an autocomplete service with these requirements:

• Response time: < 100ms (p99)
• Expected data size: 10 million terms
• Modern server hardware

How do you translate this into complexity requirements?

Step 1: Account for overhead

Not all 100ms is available for data structure operations:

• Network round-trip: ~10-30ms
• Application framework overhead: ~5-10ms
• Other processing: ~10-20ms

This leaves approximately 40-75ms for your core data structure operation.

Step 2: Estimate operation speed

On modern hardware, we can roughly estimate:

• O(1) operations: < 1μs (microsecond)
• O(log n) operations with n=10M: ~23 comparisons × ~0.5μs = ~10-20μs
• O(n) operations with n=10M: Could be seconds to minutes
• O(n log n) operations: Even worse

Step 3: Derive complexity requirement

With 40-75ms budget and n=10M:

• O(1): ✅ Trivially fits
• O(log n): ✅ ~10-20μs is negligible
• O(n): ❌ Would take seconds—1000x over budget

Conclusion: For this problem, you need O(1) or O(log n) per-query complexity. O(n) is not viable.

Common time constraint patterns:

Different system types have characteristic time requirements:

Worst-case vs. average-case considerations:

Time constraints don't apply equally to average and worst cases:

• p50 (median): What users typically experience
• p99 (99th percentile): What 1% of requests experience
• p99.9: Critical for SLAs; often contractually specified

A hash map has O(1) average-case lookup but O(n) worst-case (hash collisions). For most applications, this is fine—the worst case is rare. But for systems with strict SLAs, even rare worst cases can violate contracts and trigger penalties.

For strict worst-case requirements, consider:

• Balanced trees: Guaranteed O(log n) regardless of input
• Cuckoo hashing: O(1) worst-case lookup at cost of complex insertion
• Perfect hashing: O(1) guaranteed if dataset is static

Memory is finite, and different data structures consume vastly different amounts of it. Understanding space requirements is essential for systems that process large datasets or run in memory-constrained environments.

Components of memory usage:

A data structure's memory footprint has multiple components:

Overhead comparison:

Let's compare memory overhead for storing 1 million 8-byte integers:

Reading the table:

For simple storage of integers, an array uses ~8 MB. A red-black tree uses ~25 MB for the same data—over 3x more memory. If you have 200 GB of data and 256 GB of RAM, this difference determines whether your data fits in memory at all.

Space-constrained structure selection:

When memory is tight, apply these strategies:

1. Prefer arrays over linked structures

Linked structures (linked lists, trees) have per-element pointer overhead. Arrays have nearly zero overhead. If you don't need the flexibility of a linked structure, use an array.

2. Minimize pointer sizes

On 64-bit systems, each pointer is 8 bytes. With millions of nodes, this adds up. Techniques include:

• Using 32-bit indices into an array instead of 64-bit pointers
• Using compressed pointers (some JVMs support this)
• Using implicit structures (like binary heap in an array) that don't need explicit pointers

3. Accept write penalties for read savings

Sorted arrays are more compact than balanced trees. If write frequency is low, pay O(n) insertion to gain compact storage and cache-friendly reads.

4. Consider probabilistic structures

When approximate answers suffice:

• Bloom filters: Test set membership with ~10 bits per element (vs. 64+ for a hash set)
• Count-min sketch: Approximate frequency counts
• HyperLogLog: Approximate cardinality with fixed, tiny memory

One of the most fundamental principles in computer science is the time-space trade-off: you can often make operations faster by using more memory, or reduce memory usage by accepting slower operations. Understanding this trade-off is essential for data structure selection.

Classic examples of time-space trade-offs:

Practical trade-off decisions:

Case 1: Range sum queries

Problem: Given an array, answer many queries of the form 'sum of elements from index i to j'.

Space-optimized approach:

• Store just the array: O(n) space
• Answer each query by iterating: O(n) per query
• Total for q queries: O(q × n)

Time-optimized approach:

• Precompute prefix sums: O(n) space (doubles storage)
• Answer each query in O(1): sum(i,j) = prefix[j] - prefix[i-1]
• Total for q queries: O(q)

Trade-off: Spend O(n) extra space to reduce query time from O(n) to O(1).

Case 2: Graph representation

Adjacency matrix:

• Space: O(V²) regardless of edges
• Check if edge exists: O(1)
• List neighbors: O(V)

Adjacency list:

• Space: O(V + E) — proportional to actual edges
• Check if edge exists: O(degree) — must search neighbor list
• List neighbors: O(degree) — direct access

Trade-off: For sparse graphs (E << V²), adjacency list saves massive space with minimal time penalty. For dense graphs or frequent edge-existence queries, matrix may be faster.

How data changes—or whether it changes at all—profoundly affects data structure selection. Mutability patterns include:

1. Immutable: Data never changes after creation
2. Append-only: New data is added but existing data never changes
3. Mutable: Data can be created, updated, and deleted
4. Write-once-read-many (WORM): Like immutable, with structured creation
5. Mostly-read, rarely-written: Updates happen but are infrequent

Each pattern enables different optimizations and eliminates different structure choices.

Immutable data:

When data never changes after creation, many complexities disappear:

• No synchronization needed: Multiple readers can access without locks
• Aggressive caching: Cached values never become stale
• Sorted arrays become viable: O(n log n) sort once, then O(log n) lookups forever
• Perfect hashing possible: Know all keys upfront, design hash function to eliminate collisions
• Compact representations: No need to reserve space for growth

Example: A lookup table of country codes to country names. This data changes rarely (new countries are rare). Store as a sorted array with binary search or a perfect hash table. Never worry about thread safety for reads.

Append-only data:

When data can only be added, never modified or deleted:

• Simple crash recovery: Append to a log; replay on restart
• Efficient writes: No need to find and update existing records
• Compression-friendly: Can compress historical data knowing it won't change
• Log-structured structures work well: LSM trees, append-only B-trees

Example: Event sourcing systems, audit logs, blockchain ledgers. Data is only ever added; historical records are sacrosanct.

Mutable data:

Full mutability (insert, update, delete) requires the most complex structures:

• Locking or lock-free structures needed: Concurrent access requires synchronization
• Dynamic structures required: Must handle growth and shrinkage
• Balancing overhead: Tree-based structures need rebalancing; hash maps need resizing
• No stable addresses: Element positions can change; pointers into structure become invalid

Example: Active user sessions, shopping carts, in-progress transactions. Data changes constantly; structures must support efficient updates.

Write-once-read-many (WORM):

Like immutable, but with a structured creation phase:

• Two-phase lifecycle: Build phase (mutable) → freeze → read phase (immutable)
• Enables construction then optimization: Sort during build, binary search during read
• Common in data pipelines: Build index offline, deploy for serving

Example: Search engine indexes. Build the inverted index from crawled data (hours), then serve queries from the frozen index (milliseconds per query).

In modern systems, data structures are rarely accessed by a single thread. Concurrency requirements can eliminate otherwise-optimal structures or require significant modifications.

Concurrency patterns:

Single-threaded: Only one thread ever accesses the structure.

• Any structure works
• Simplest to implement and reason about
• Becoming rare in production systems

Read-mostly, rare writes: Many readers, occasional writers.

• Read-write locks can work well
• Copy-on-write enables lock-free reads
• Consider immutable snapshots for readers

Concurrent reads and writes: Both happen simultaneously.

• Requires thread-safe structures or careful synchronization
• Lock-free structures offer better scalability
• Partitioning can reduce contention

High-contention writes: Many threads frequently modifying the same data.

• Most challenging pattern
• May require fundamental design changes
• Consider eventual consistency, sharding, or redesign

Structure-specific concurrency considerations:

Arrays: Generally not thread-safe. Appending during iteration is undefined. Use synchronization or concurrent array types.

Linked lists: Single-pointer updates can be atomic, but multi-pointer operations (like insertion) require care. Lock-free linked lists exist but are complex.

Hash maps: Concurrent access to different buckets can be safe; same-bucket access needs synchronization. Concurrent hash maps use fine-grained locking or lock-free techniques.

Trees: Rebalancing affects multiple nodes, making concurrency difficult. Fine-grained locking (lock coupling) or lock-free variants exist for B-trees.

Queues/Stacks: Producer-consumer patterns map well to lock-free implementations. These are among the most practical lock-free structures.

Real systems face multiple constraints simultaneously, and these constraints often conflict. Navigating these trade-offs is where engineering judgment becomes essential.

Common constraint conflicts:

Conflict 1: Fast reads vs. fast writes

Optimizing for reads often comes at the expense of writes and vice versa:

• Sorted arrays: O(log n) reads, O(n) writes
• Unsorted arrays: O(n) reads, O(1) writes
• Balanced trees: O(log n) for both—a compromise
• Write-ahead logging: O(1) writes, periodic read reorganization

Resolution strategy: Match to your read/write ratio. A 1000:1 read-to-write ratio should optimize for reads; a write-heavy system should optimize for writes.

Conflict 2: Memory efficiency vs. operation speed

Compact structures often require more computation:

• Compressed data saves space but requires decompression
• Computed values (vs. stored) save space but require recomputation
• Bitmap indices are compact but require bit manipulation

Resolution strategy: Profile both memory and CPU usage. Sometimes memory pressure (swapping, cache misses) causes more CPU impact than just computing values directly.

Conflict 3: Consistency vs. performance

Strong consistency guarantees slow things down:

• Locks serialize access, reducing throughput
• Transactions add overhead
• Distributed consensus requires network round-trips

Resolution strategy: Define exactly what consistency you need. Many systems that claim to need strong consistency actually function correctly with eventual consistency, especially for analytics or caching.

Let's apply constraint analysis to a realistic problem.

Problem: Real-time user presence system

Build a system that tracks which users are currently online. Requirements:

• 50 million registered users
• At peak, 5 million users online simultaneously
• Check if a specific user is online: needed for every message send
• Get list of online users from a specific list (e.g., friends): needed for presence indicators
• Users come online/offline constantly: ~100,000 status changes per second at peak
• System must fit in 16 GB RAM (it's one of several services on the machine)

Constraint analysis:

Time constraints:

• Is-online check happens per message: must be O(1) or very fast O(log n)
• At 10,000 messages/second, each check must average < 100μs
• Status updates at 100K/second: each update must average < 10μs

Space constraints:

• 16 GB available
• 50M users × 8 bytes user ID = 400 MB minimum payload
• Need structure overhead + operational headroom
• Budget: ~4 GB for presence structure (leaving room for other service data)

Mutability constraints:

• Highly mutable: 100K+ updates per second
• Both inserts (come online) and deletes (go offline)

Concurrency constraints:

• Multiple handler threads processing messages simultaneously
• Status update handlers separate from query handlers
• Read-heavy but writes are continuous

Candidate evaluation:

Option 1: Hash set of online user IDs

• Is-online check: O(1) ✅
• Insert/delete: O(1) ✅
• Space: 5M users × (8 byte ID + 8 byte pointer + overhead) ≈ 120 MB ✅
• Concurrency: Need concurrent hash set implementation
• Get friends online: O(friends) — must check each friend individually

Option 2: Bitmap (one bit per user)

• Is-online check: O(1) ✅
• Insert/delete: O(1) ✅
• Space: 50M users × 1 bit = 6.25 MB ✅ (very compact!)
• Concurrency: Bit operations can be atomic
• Get friends online: O(friends) — same as hash set

Option 3: Set per user list (for group queries)

• Would need to maintain group membership + intersection
• Space: Explodes with user-group combinations
• Complexity: High maintenance overhead

Decision:

Bitmap wins for this use case:

• 20x more memory-efficient than hash set
• O(1) operations with excellent cache behavior (single memory fetch for 64 users)
• Atomic bit operations provide natural thread-safety
• User IDs can be mapped to bit positions via simple array or minimal perfect hash

The extreme memory efficiency of bitmaps makes them ideal for presence/online-status systems with large user bases.

Constraints transform data structure selection from an open-ended question into a bounded decision problem. By understanding and applying constraints, you can quickly narrow candidates and make defensible choices.

What's next:

Knowing the right approach isn't enough if you fall into common traps. The next page examines common beginner mistakes in data structure selection—the patterns that lead developers astray even when they know better. Understanding these anti-patterns helps you avoid them in your own work.