Yummy Pizza

Pitch Video:

https://github.com/EEddeenn/YummyPizza/raw/refs/heads/main/docs/pitch/Yummy_Pizza_Obsidio_Pitch_Final.mp4

Inspiration

Yummy Pizza began with a simple question: how much performance can we extract from two CPU cores without compromising correctness? The challenge looked like a small financial API, but its four routes behaved very differently. Price lookups were tiny, statistics required scanning 500 values on every request, and risk calculations performed 50,000 chained SHA-256 hashes. Under load, one expensive route could easily delay everything else. That made the project more than a speed contest. It became an exercise in scheduling, measurement, and making deliberate trade-offs under a strict resource budget.

What we built

We built Obsidio as a compact C++23 HTTP service for the competition’s 2 CPU, 2 GB environment. Its architecture combines:

• A single Boost.Asio reactor that owns every socket.
• Allocation-light HTTP parsing and response generation.
• Preformatted price responses and a validated perfect hash for symbol lookup.
• SIMD-friendly statistics that still recompute all 500 values per request.
• Specialized SHA-256 implementations for x86 SHA-NI, Arm SHA2, and portable scalar machines.
• Two bounded risk workers that keep expensive hashing away from the reactor.
• Optional crash-safe price persistence without placing filesystem work on the scored request path. The workload assigns different values to completed operations: [ S = N_{\text{price}} + 3N_{\text{stats}} + 10N_{\text{risk}} ]This meant that maximizing raw request count was not enough. We had to preserve fast routes while keeping the high-value risk pipeline busy.

How we built it

We started with profiling rather than assumptions. The first profiles showed that hashing set the computational cost, while queueing and thread contention determined how much useful work reached the finish line. We optimized one layer at a time:

1. Removed unnecessary allocation and formatting from the HTTP path.
2. Reorganized market data for cache-friendly price and statistics access.
3. Specialized the repeated SHA-256 feedback message instead of treating every round as arbitrary input.
4. Used SHA-NI instructions and interleaved two, then four, independent hash chains to expose instruction-level parallelism.
5. Introduced a bounded worker queue so expensive requests could not overwhelm the reactor.
6. Added conservative overload shedding to keep latency bounded while staying within the competition’s error limit.
7. Pinned the Fedora, Clang, LLVM, GCC runtime, and linker versions so reviewer builds reproduce the measured toolchain. We also built our own native stress driver for controlled experiments, while retaining the organiser’s k6 workload as the final grading cross-check.

Challenges we faced

The hardest problem was not implementing a faster hash. It was making the entire system faster under the mixed workload. Three runnable threads—the reactor and two risk workers—had to share only two cores. More workers improved hashing capacity but could starve networking. Larger queues increased utilization but also increased tail latency. Aggressive rejection could improve throughput while failing the error-rate gate. Some promising ideas did not survive measurement. We explored a two-shard architecture in which each core owned its sockets and local work, but the implementation risk and uncertainty were too high near the deadline. We kept the simpler reactor architecture because it was measured, explainable, and reliable. Persistence introduced another challenge. A successful price update had to survive an immediate container kill, but filesystem synchronization could never block the reactor. We solved this with a dedicated sleeping storage thread and a two-slot, generation-numbered snapshot format protected by CRC checks. Reproducible builds were also harder than expected. Fedora’s rolling repositories removed an exact GCC package version shortly before handoff. We retained the benchmarked compiler stack by resolving the pinned packages through Fedora’s official updates archive instead of silently changing toolchains.

What we learned

The largest lesson was that local improvements do not automatically improve the final score. A microbenchmark can show that a kernel became faster, but only the complete workload reveals whether that improvement survives queueing, connection handling, CPU contention, and latency limits. We learned to use profiles to explain behavior, paired comparisons to choose between alternatives, and the organiser’s full workload to make the final decision. We also learned the value of rejecting ideas. A technically interesting design is not automatically the right design to ship. Resilience came from bounded work, explicit ownership, reproducible evidence, and knowing when the current architecture was already good enough.

Result

Our final predeclared organiser-k6 confirmation produced:

• 6,225,477 weighted points
• 23,057.208 points per second
• 3.981 ms price p95
• 3.991 ms statistics p95
• 185.344 ms risk p95
• 0.777697% overall error rate All competition thresholds passed in the capped 2 CPU, 2 GB environment.

Yummy Pizza is Shangren Lu, Clarke, and Zoey. We built a small service, but the real project was learning how architecture, hardware instructions, measurement, and engineering judgment work together under pressure.

Built With

• c++
• docker