Distributed community + marketplace platform
A distributed ecosystem of community forums and marketplaces — Google Maps proximity discovery, real-time threads and RTK Query at scale. Co-architected at SELISE Digital Platforms.
- Live
- Forums + marketplace
- Geo radius discovery
By the numbers
- Community surface
- Forums
- Marketplace surface
- Market
- Geo discovery
- Maps
- Realtime updates
- Realtime
01The problem
Community platforms either grow into clones of one another (text threads, no location, no commerce) or split features across half a dozen apps. The brief was to build a single distributed ecosystem — community forums plus a marketplace — where discovery is anchored to the user's location, not a national feed. People should see nearby items within a configurable radius, forum threads have to stay snappy at scale, and the whole interface needs to feel like one product even though forums and marketplace listings have very different update patterns.
02What we built
- 01
Google Maps API integrated with a custom radius-based proximity filter — users see marketplace items and community posts pinned to their location, with the radius configurable per query so a city user gets different results than a small-town one.
- 02
Real-time forum threads and marketplace listings powered by RTK Query — caching, invalidation tags and tag-aware refetch keep the feed coherent even as multiple users update the same thread.
- 03
Optimistic updates across the interaction surface — likes, comments, marketplace bids and threaded replies all update locally before the server confirms, so the UI never blocks behind network latency.
- 04
Distributed state management with Zustand alongside Redux Toolkit — Zustand owns the local interaction state (lightboxes, drawers, transient UI) while RTK owns the cached server contract, so the two layers don't fight over the same source of truth.
- 05
A moderation backplane — reported items queue, content takedown, geo-fence config and policy-based role gates, so the platform can grow without operations turning into a full-time job.
- 06
A notification fan-out path on the API — a single threaded reply or new marketplace listing fans out to subscribers without flooding the database with N+1 lookups.
03Stack
Community UI
- Next.js
- TypeScript
- Tailwind
- Google Maps API
- Optimistic UI
- Infinite scroll
- Skeleton states
- Image CDN
Moderation + policy
- Moderation queue
- Content takedown
- Reported items
- User policy
- Geo-fence config
- Spam heuristics
- Audit log
- Role gates
State + delivery
- Redux Toolkit Query
- Zustand
- Distributed state
- Real-time threads
- Radius filter index
- Marketplace search
- REST contract
- Notification fan-out
04The hard part
The hardest part was making proximity discovery feel native without dragging a heavy GIS layer into the application. A radius filter on lat/long is a few lines of SQL; making it feel like a real product means pre-indexing for the queries the UI actually issues (nearby items first, sorted by recency within radius, then by relevance), throttling map re-fetches as the user pans, and degrading gracefully on devices that block geolocation. The map had to be a first-class surface, not an afterthought card.
The second hard part was state ownership across two interaction patterns — forums (long-lived threaded content) and marketplace listings (transactional, short-lived). RTK Query is great at caching server contracts; Zustand is great at fast local interaction. Splitting them along that line — RTK owns the cache, Zustand owns the transient — meant the two layers never had to reconcile the same row, and the optimistic UI could stay responsive even when the cache was mid-refetch. That split is the reason the interface stays fast at scale.
Your move
Want one built around your operation?
We take on a small number of custom engagements per year. If this looks close to a problem you have, tell us about it.