b_llc

Cloudflare R2 bills on writes ($4.50/M), reads ($0.36/M), and storage ($0.015/GB/mo). The free tier gives you 1M writes, 10M reads, and 10GB per month. If you batch uploads hourly, you only make ~720 writes a month. That completely eliminates write costs, leaving storage as the only expense.

A stateless pattern I use to batch telemetry at the edge while driving Cloudflare write costs to zero.

What does Hacker News make of Meta's decision to abandon regional DAU for DAP. This change effectively hides their extreme North American ARPU concentration.

Do you think they intentionally hid the KPI to avoid scaring investors?

I'd like to thank everyone for the feedback.

I'm going to reflect on the feedback, rewrite the article with better explanations of the problem domain, and its limitations. I've clearly failed to articulate the core capability: dynamic file bundling via query parameters into a unified multipart stream.

I'll check back over the next few days but won't be monitoring constantly. If you want to discuss this project privately, I’m available by email.

The code is 100% mine. The architecture and code evolved over 5-years as Axon adapted for a number of projects. I started to revamp the project 2-3 weeks ago. Throughout that process, I used Claude to check for logical errors and simplification opportunities. Claude generated the readme and shell scripts in entirety and commented the codebase for clarity.

Edit: The hello-world.html was also generated.

You're right about boundary caching opportunities. The computational cost I'm referring to comes from the construction of the per-request multipart header, and file metadata operations, rather than just boundary generation.

The "inherently expensive" claim was overstated - it's expensive relative to static file serving, and unavoidable, but you're correct that there are optimization opportunities in the current implementation. I've identified three opportunities to improve the design: boundary generation, content type assignment, and header construction.

One clarification: the dynamic bundling via query parameters limits traditional caching strategies. Since each request can specify different file combinations, the multipart response structure must be generated per-request rather than cached.

Axon also represents a core framework. How you implement caching depends on your specific use case - this becomes business logic rather than request processing logic. Its minimal tooling is intended to be a feature, though, as you have pointed out, it can also be limiting.

I might be wrong then! I'll make a note to take a look. Thanks for pointing this out.

Axon generates dynamic multipart responses with boundaries and headers to bundle files specified via query parameters. sendfile handles "serve this specific file" but does not handle "bundle these N files into a multipart response."

For static file serving, sendfile would be the better choice.

You're right - this represents computational duress, not optimal efficiency. The 1 CPU struggles to handle the 50 concurrent user scenario and was chosen to demonstrate worst-case behavior rather than peak performance. I intended to stress test the framework. I did not mean to indicate that CPU saturation is ideal but rather highlight that performance remained predictable even at the limits.

Lower-level languages would certainly offer higher performance. I was hoping to showcase how Python can perform when architecture is restrained. The goal was to show that careful design choices (bounded memory, generator-based streaming) can maintain predictable behavior even when computational resources are exhausted.

By I/O limits, I meant network bandwidth and disk throughput limits, not memory capacity.

Thanks for pointing out the ambiguity.

Good question! Yes, CPU saturation is the desired behavior here.

The multipart streaming workload is inherently expensive. The cost of generating boundaries and constructing headers scales with request count and payload size. The architecture demonstrates efficient resource utilization: bounded memory usage (<225MB) while maximizing CPU throughput.

CPU saturation with bounded memory means performance scales predictably with processing power. On multicore systems, you can leverage multiple processes to effectively utilize all cores. Alternatively, you can distribute the workload horizontally using droplets as cost-efficient instances.