FediMeteo Optimizes Infrastructure with HAProxy to Preserve Lightweight Design
#Infrastructure

FediMeteo Optimizes Infrastructure with HAProxy to Preserve Lightweight Design

DevOps Reporter
2 min read

The FediMeteo weather service for the Fediverse has implemented a sophisticated HAProxy configuration to maintain its lightweight architecture as it scales. By caching public responses, routing efficiently, and minimizing backend requests, the service preserves its original design philosophy while handling growing traffic.

FediMeteo, the weather service built for the Fediverse, has evolved from a personal project into a global service while maintaining its commitment to simplicity and efficiency. As the service has grown, its architect has implemented a carefully tuned HAProxy configuration to reduce the load on the snac backends, ensuring that the service remains lightweight and responsive.

The FediMeteo service publishes weather forecasts as text and emoji across multiple country-specific accounts, following the ActivityPub protocol. What began as a small experiment has expanded to serve numerous countries under domains like fedimeteo.com, it.fedimeo.com, uk.fedimeo.com, and many more. Each country runs its own instance in a FreeBSD jail, with a single entry point handling all incoming requests.

The key challenge has been maintaining efficiency as the service scales. In the Fediverse, public objects like user profiles and posts are frequently requested by remote instances, browsers, and preview services. Without proper caching, these repeated requests can consume valuable backend resources.

The solution implemented uses HAProxy not just as a load balancer, but as an intelligent caching layer that absorbs repetitive public requests before they reach the snac backends. This approach preserves the limited thread model of snac, which the author values as "healthy" and forcing "us to understand what the service is doing."

One clever optimization is the use of a single shared avatar across all country accounts. This creates a highly cacheable object that's frequently requested and remains consistently "hot" in the cache. The author notes that this decision was not just visual but architectural: "With one shared avatar, the reverse proxy has one very useful object to cache. It is public, identical for everyone, small, requested often, and therefore almost always hot in cache."

The HAProxy configuration includes two separate caches: one for media (primarily the shared avatar) with a 3600-second max age, and another for ActivityPub JSON responses with a shorter 60-second cache. The shorter JSON cache is designed to collapse repeated requests that arrive close together in time without treating ActivityPub responses as immutable files.

Comments

Loading comments...