Software's Rush E

Status: UNSOLVED

Before We Begin

Do you know Rush E?

If you do, you'll probably understand where this challenge gets its name.

If not, take a few minutes to read this Reddit thread:

In short, Rush E became famous because it starts like a normal piano piece, gradually becomes more complex, and eventually reaches a point where it is considered practically impossible for a single human to perform.

It has become an internet symbol for something that pushes skill beyond its limits.

This challenge follows the same philosophy.

It starts with what appears to be a fairly ordinary event-processing engine.

Then the constraints begin to pile up.

Every optimization introduces another problem.

Every solution creates another bottleneck.

Eventually, you stop asking:

"How do I implement this?"

and start asking:

"Is this even possible?"

Welcome to our Rush E.

Your Task

Implement an engine capable of processing an unbounded event stream.

Only one public function exists.

process(Event event)

Everything else is your responsibility.

Event Model

Each event contains:

Event ID
Timestamp
Priority
Transaction ID
Dependency Graph
Payload
Routing Metadata
Version
Checksum

Additional fields may appear without warning.

Unknown fields must never break the engine.

Stage I — The Warm-Up

Incoming traffic begins slowly.

1,000 events/sec

Then increases.

100,000 events/sec

Then again.

1,000,000 events/sec

Then again.

10,000,000 events/sec

After that, the benchmark no longer guarantees any upper bound.

Traffic patterns become unpredictable.

Stage II — Hidden Dependencies

Some events are completely independent.

Others depend on one previous event.

Some depend on thousands.

Dependencies are discovered only during execution.

An event must never execute before all of its dependencies have completed successfully.

Independent work should execute concurrently whenever possible.

Stage III — Causality

Ordering rules are strict.

For every dependency chain:

A → B → C → D

The observable result must always preserve causality.

Events without dependencies may execute in parallel.

Events with dependencies may not.

Stage IV — Atomicity

Events may belong to distributed transactions.

Transactions may:

begin
commit
rollback
timeout
retry

Partial visibility is forbidden.

A transaction either exists completely or not at all.

Stage V — Chaos

At any moment the benchmark may:

increase event size
increase dependency depth
create hot keys
generate hash collisions
produce highly skewed traffic
replay old events
duplicate events
inject malformed events

The engine must continue operating correctly.

Stage VI — Scarcity

Available resources:

CPU Cores: 4
Memory: 512 MB

During execution the benchmark may reduce both.

No restart is allowed.

Stage VII — Memory

After initialization:

No unbounded memory growth
No memory leaks
No excessive fragmentation
Efficient cache utilization is expected

The benchmark continuously monitors memory usage.

Stage VIII — Time

The scheduler is adversarial.

Threads may be paused at any instruction.

Context switches are unpredictable.

Race conditions are considered implementation failures.

Deadlocks fail immediately.

Livelocks fail immediately.

Starvation fails immediately.

Stage IX — Failure

Without warning, the benchmark may:

terminate the process
restart the process
reorder network packets
duplicate packets
delay packets indefinitely
partition the network
corrupt clocks
introduce clock drift
simulate hardware failures

Recovery must be automatic.

Stage X — Determinism

The entire execution may be replayed.

Every replay must produce:

identical state
identical outputs
identical transaction history
identical checksums

Bit-for-bit determinism is required.

Stage XI — The Unknown

The benchmark intentionally hides:

hardware topology
CPU cache hierarchy
NUMA layout
workload distribution
dependency density
replay frequency
event locality

The environment may change between executions.

Stage XII — The Finish Line

The benchmark continuously records:

Throughput
Average latency
p95 latency
p99 latency
p99.9 latency
Maximum latency
CPU utilization
Memory utilization
Allocation count
Cache misses
Branch mispredictions
Context switches
Recovery time

Correctness always takes priority over performance.

Performance without correctness receives a score of zero.

Correctness Requirements

Your engine must guarantee:

No lost events
No duplicated observable effects
Dependency correctness
Serializable transactions
Deterministic execution
Crash recovery
Replay correctness
Snapshot consistency
Exactly-once observable behavior

Every requirement must hold simultaneously.

Deliverables

Provide:

Source code
Design document
Architecture diagram
Concurrency model
Memory management strategy
Failure recovery strategy
Complexity analysis
Benchmark results
Correctness justification

Final Evaluation

Your implementation is considered successful only if every requirement remains true under every workload and every injected failure.

There are no partial passes.

Final Note

Some requirements may be fundamentally incompatible.

Identifying and justifying those incompatibilities is considered part of the challenge.

The benchmark is deterministic.

The workload is not.

The failures are not.

The scheduler is not.

The hardware is not.

Every optimization creates another bottleneck.

Every bottleneck exposes another optimization.

Maybe the goal was never to solve the challenge.

Maybe the goal was to discover where computer science itself reaches its limits.

If you think you've solved it...

Read the specification again.

Good luck.

You'll need it.