Architecture of the reboot

The reboot used different systems for workloads with different access patterns. Rails 5.2 served the application shell and JSON APIs, handled authentication and permissions, and coordinated writes. The browser application used React 15, Backbone models and events, and a custom Flux-style dispatcher and stores.

Durable publishing in Cloudant

IBM Cloudant held posts, feeds, users and tags. Its CouchDB-compatible document model suited content whose shape changed as the editor gained richer blocks and media. Design-document views supplied feed, contributor, response, tag and ranking queries without forcing evolving posts into relational rows.

Fast reads required denormalisation. Publishing could affect feed indexes, response counts, tag statistics, notifications and community events. Rails accepted the intent; Redis-backed Resque workers performed that fan-out and retried derived updates away from the request.

Immediate interaction in Firebase

Firebase Realtime Database held interaction data that benefited from live updates, including votes, semantic reactions, bookmarks, reports, endorsements and activity. React components subscribed to narrowly scoped paths, so a count or state could change without fetching the durable post again from Cloudant.

Media outside the request path

Cloudinary accepted image uploads and produced cropped, resized and pixel-density-aware variants for headers, avatars, cards and posts. Embedly turned pasted URLs into structured previews for links and video. Both kept expensive processing and provider-specific behaviour out of the main Rails request.

The split was not free: consistency had to be explicit, background work needed retries, and the client had to reconcile durable content with live interaction. It worked because each boundary followed a real access pattern rather than introducing another system for its own sake.