Backend Upgrade: A Faster Gallery and a Steadier Publishing Queue
Infrastructure work behind Wallper: streamlined browse and preview endpoints, lower p95 latency during upload bursts, and better visibility into the publish queue.
A desktop app with an online library is really two products, and only one of them is on your Mac.
The other is the service behind it: the thing that answers when you open the gallery, serves previews as you scroll, and accepts wallpapers when creators publish them. When that service is slow, the app is slow, and no amount of work on the client side can hide it.
October was spent on that half.
Browse and Preview
The hot endpoints, the ones hit constantly while browsing and previewing, were streamlined.
These are the requests that run whenever anyone opens the library, which makes them both the most frequent and the least forgiving. Everything else can afford to take a moment. These cannot, because they sit directly between someone scrolling and the thing they are scrolling through.
Latency Under Upload Bursts
p95 latencies are down under bursty creator uploads.
The p95 figure is the one worth tracking. An average hides the problem entirely: if nineteen requests are fast and the twentieth takes four seconds, the average looks fine and one person in twenty has a bad time. Optimising for the slowest requests rather than the typical ones is what stops the library feeling unreliable.
Upload bursts are the specific pressure here. Publishing is not evenly distributed. Creators upload in batches, often several at once, and that load previously showed up as slowness for everyone else browsing at the same time. It no longer does.
Observability
Better instrumentation around queueing and cache invalidation.
This is the change with no user-visible effect and the longest tail of benefit. Publishing problems used to be reported by creators rather than detected by us, which meant the fix started with reconstructing what had happened from a description. Now the queue reports on itself, which is the difference between a problem being noticed on a dashboard and being noticed in a support message.
The results are visible in the releases that followed, particularly the publishing fixes in 1.3.1 and 1.3.4.
