Building a privacy-first real-time social platform
View engineering work on GitHub↗Executive Summary
Asteria was an early product platform spanning web, mobile, backend services, and real-time communication. The system was designed around a privacy-first social experience with encrypted messaging, real-time presence, feeds, notifications, authentication, and background processing. Unlike a simple CRUD application, Asteria had to coordinate several workloads with very different requirements: persistent user data, high-frequency real-time events, asynchronous jobs, cached feeds, and privacy-sensitive communication. The project became an exercise in designing a backend that could keep these concerns modular while still providing a coherent product experience.
The Challenge
The difficult part was not implementing individual features. It was making them operate together without creating a backend where every component depended directly on every other component. Real-time communication introduced state that could not simply live inside one server process. Multiple application instances needed to know about WebSocket events generated elsewhere. Background work needed to happen without blocking user-facing requests. Feeds required repeated reads of data that could become expensive as activity increased. Authentication and messaging also introduced security and privacy requirements that affected the system beyond the immediate feature being implemented. The architecture therefore needed clear boundaries between synchronous application requests, persistent storage, cached state, asynchronous workers, and real-time communication.
The Approach
We built the backend in Go with PostgreSQL and Redis, using Redis Pub/Sub to coordinate WebSocket events across multiple application instances. This allowed real-time communication to remain distributed rather than being tied to the memory of a single server. Background workers handled operations that did not need to block the request-response cycle, while feed caching reduced repeated database work for frequently accessed content. The product layer incorporated OTP and OAuth authentication, real-time messaging, user statuses, notifications, and privacy-sensitive communication. Rather than treating each feature as an isolated implementation, the system was organized around service boundaries and shared infrastructure so the product could evolve without every new capability increasing the complexity of the entire backend.
The Impact
Asteria demonstrated the ability to take a product from application architecture through implementation across web, mobile, backend, and real-time infrastructure. The project required practical decisions around distributed state, WebSockets, caching, asynchronous processing, authentication, and privacy-sensitive data. It also reinforced an important engineering principle: scalability is not achieved by adding infrastructure after a product becomes successful. It begins with deciding which parts of the system should communicate directly, which should communicate through events, which state should be persistent, which state can be cached, and which workloads should happen outside the critical request path.
What’s sitting on your engineering backlog?
Give us one task. We’ll take it from scope to production while your team keeps building the core product.