Single JSON serialization for DB and S3

[jmg-duarte]

Description

Serialize the raw auction data a single data, instead of one per persistence method

Changes

• Replaces the S3 and DB upload functions with a single one that serializes the JSON once

How to test

Ran it last night in mainnet prod, the dip around 22 was when it was deployed

[claude]

Claude finished @jmg-duarte's task in 2m 48s —— View job

---

PR Review: Single JSON serialization for DB and S3

• Read changed files & diff
• Analyze correctness/behavior changes
• Post inline review comments

Nice, clean refactor. Collapsing the two independent serializations (DB via to_string, S3 via upload→to_vec) into a single serde_json::to_vec shared as Bytes removes the previous double serialization and the two deep clones of the domain auction (from_domain now borrows and the auction is handed back to the caller). Behavior is preserved: DB write is unconditional, S3 upload still skipped for empty-order auctions, and the enqueue-before-S3 ordering is intact. The serialization-failure path is actually cleaner than before (fails fast without a phantom enqueue).

One trade-off worth being aware of (already acknowledged by the code comment): serialization now sits on the run loop's critical path, whereas before both serializations happened entirely in background tasks. The production graph and the serialize_auction overhead metric cover this, so it looks intentional and measured.

Only one minor, optional nit posted inline (Bytes::from vs Bytes::from_owner). Nothing blocking.

[MartinquaXD]

The idea makes sense to me but the current implementation leaves some performance on the table IIUC.

[MartinquaXD]

I think we could avoid re-checking that this is valid utf8 by passing the AuctionUpload struct directly and making its constructor do the serialization. That way we know the immutable bytes we get from the AuctionUpload struct is not only valid utf8 but even valid JSON.
In the end we can just cast the bytes to a string in the DB query IIRC. At the very least that should at least move the re-validation into postgres if it doesn't skip it outright.