Skip to main content
Let’s zoom out and revisit the photo-app architecture we’ve built so far. This overview shows how incoming requests flow, where state is stored, and how we scale reads and writes to meet production traffic. When a user opens the photo app, the request first hits the load balancer. The load balancer forwards the request to one of our stateless application servers (we currently run 10). Because the application servers are stateless, any server can handle any user request, which simplifies scaling and failover. Request flow (high level):
  • Client → Load Balancer → Stateless App Server → Cache → Database(s)
Session management
  • All user login sessions are stored centrally in Redis. Centralized sessions let any app server authenticate a user without sticky sessions, enabling seamless scaling and server replacement.
Store sessions in a dedicated Redis cluster configured with persistence (RDB/AOF), eviction policies, and clustering to avoid session loss and bottlenecks. For very high security requirements, couple Redis session data with short TTLs and server-side session validation.
Caching strategies
  • For frequently accessed (“hot”) data—trending photos, popular profiles, or feed fragments—the application checks the cache (Redis or a dedicated cache layer) before querying the primary database.
  • Cache synchronization with Postgres uses TTLs and explicit invalidation when data changes. Common patterns:
    • Write-through: write to cache and DB synchronously for strong consistency.
    • Write-back: write to cache first and flush to DB later for high write throughput.
    • Explicit invalidation: update DB then delete/refresh cache on change.
Note: Cache invalidation is one of the hardest problems in distributed systems—choose a pattern based on consistency vs. latency trade-offs. Primary and read-scale database (Postgres)
  • Structured entities—users, photos, likes, comments, follows—are stored in Postgres with indexed columns for common queries.
  • To scale read throughput, we run one primary that accepts all writes and two read replicas for read traffic. A read load balancer distributes queries to replicas (and optionally the primary).
Read replicas often replicate asynchronously. Expect replication lag: reads served from replicas may be eventually consistent. Design UX and critical reads to tolerate or avoid stale data (e.g., read-your-writes scenarios).
Additional data stores
  • MongoDB (NoSQL) holds unstructured or semi-structured data such as user preferences, activity streams, and behavioral events where flexible schemas are helpful.
  • If dataset size grows beyond a single instance’s capacity, use sharding/partitioning to split data across machines and scale horizontally.
Operational considerations
  • Configure Redis for persistence and clustering; tune eviction policies for session vs. cache data.
  • Monitor replica lag, index usage, and cache hit rates.
  • Automate backups and test failover procedures regularly.
Component responsibilities (quick reference) References and links If the dataset grows beyond what a single database instance can hold, we can partition the data using sharding to split it across multiple database machines.
The image is a diagram of a server architecture featuring a user interacting with a stateless server setup through a load balancer, with caching, session management, and data storage systems using Postgres and MongoDB.
This diagram summarizes the complete design so far. As requirements evolve—higher throughput, lower latency, stronger consistency guarantees—we will add components and apply optimizations such as CDN edge caching, async job queues, rate limiting, and more advanced database partitioning.

Watch Video