Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
System Architecture
GitHub Logo

Shared Virtual Workouts for Connected Fitness

Bring live movement and saved progress together in Harper for responsive shared workouts and simpler regional growth.
Real-time
System Architecture
Real-time

Shared Virtual Workouts for Connected Fitness

Harper
at Harper
October 12, 2026
Harper
at Harper
October 12, 2026
Harper
at Harper
October 12, 2026
October 12, 2026
Bring live movement and saved progress together in Harper for responsive shared workouts and simpler regional growth.
Bring live movement and saved progress together in Harper for responsive shared workouts and simpler regional growth.
Harper

A rider accelerates to rejoin a group, but the other riders still see them falling behind. A runner reconnects and expects the distance they already covered to count toward their workout. For connected fitness, responsive movement and reliable progress help make the experience worth returning to. Delays, sudden jumps, or lost effort can undermine confidence and give members a reason to stop using the service.

How Harper brings shared workouts together

Harper brings application APIs, live participant data, saved progress, and messaging together behind the fitness client. The client reads the equipment, calculates movement and much of the workout progression, and renders the world. It sends position and progress updates to Harper, where application logic checks the data, stores it, and makes live changes available to other participants.

Live positions and earned progress have different needs. Positions change frequently and expire when a participant stops reporting. Progress is saved separately and reconciled with what Harper already holds, helping an older device or retry avoid overwriting newer totals. Clients subscribe to nearby areas of the virtual world so they receive relevant movement rather than every update from every participant.

The blocks inside Harper are capabilities of the same runtime, not separate services to deploy. Application APIs accept activity and progress updates, while native messaging sends changes to subscribed clients. On joining or reconnecting, the client fetches the current nearby participants. If live messaging is interrupted, it can continue requesting updates while it reconnects, helping keep the group visible.

Fabric manages regional deployment, replication, routing, and failover. Teams can add a region in a few clicks by selecting the location and confirming the change, bringing the backend closer to more participants. The client keeps local movement responsive, while application rules reconcile saved progress and choose the newest position updates as data moves between regions. This design doesn't require a central server to calculate every participant’s movement.

Alternatively, connecting application servers, storage, and messaging

A conventional backend can use application servers to receive position and progress updates, Redis for live participant data, PostgreSQL for saved progress, and an MQTT broker to deliver changes. The client still calculates movement, connects to the equipment, and renders the world. These familiar services can scale independently, with the application coordinating storage and publication.

The diagram shows one serving location. Participants farther away face longer network trips before others receive their updates. Teams can deploy the backend across regions to shorten those trips, then coordinate data replication, message delivery, and recovery across locations.

Where a reconnect becomes more than a connection problem

When a rider reconnects, the client needs a current view of nearby participants and saved progress that does not move backward. Late position updates should not replace newer ones, and repeated progress writes should not count the same effort twice. Separate services add coordination to that recovery path. Harper puts the APIs, storage, and messaging together so those rules involve fewer systems to connect and operate.

Why Harper matters

  • A workout members want to return to. Responsive group movement and reliable saved progress support confidence in the experience and give teams a foundation for improving retention.
  • Less infrastructure work. Bring application APIs, stored data, and messaging together so engineers can spend more time improving rides and runs.
  • More efficient live delivery. Send relevant updates to the right participants, limiting unnecessary traffic and processing as groups grow.
  • Easier regional expansion. Add regions in a few clicks and bring the backend closer to participants, with Fabric managing deployment and replication.
  • A simpler recovery path. Keep workout records and recovery logic together, with regional failover supporting the application’s reconnect flow.

Plan for consistent progress and useful live updates

Give each activity update an identity and an order within its workout. Define how the application handles repeats, late arrivals, implausible readings, and interrupted saves. Live positions can be replaced by newer updates. Earned progress needs durable records and recovery rules that prevent lost or duplicated credit.

Authenticate participants and restrict subscriptions to the data they may access. Define how updates from different devices and regions are reconciled. Keep client feedback responsive during network delays, then refresh nearby participants and reconcile saved progress when connectivity returns. Use additional server-side validation where competitive rankings or rewards require stronger verification of reported effort.

Related resources

See connected fitness in action. Request a demo to see treadmill and cycling activity in a shared virtual world, with live participant updates and saved progress.

Getting Started PubSub provides Harper messaging examples using MQTT, WebSocket, and server-sent events. ACL Connect is a reference for MQTT publisher and subscriber permissions. Use these as starting points for messaging and access control, then add the workout rules and equipment integration.

See Fabric cluster management for adding regions and managing deployment.

Start with one shared ride or run

Pilot one shared ride or run with representative equipment, connection quality, and group sizes. Measure the time from activity input to another participant’s view, saved-progress accuracy, recovery time, and cost per active participant. Track workout completion and repeat participation to assess the member experience. Test retries, interrupted saves, reconnects, and regional failures before expanding.

Bring your workout flow, equipment integrations, and target audiences to a Harper architecture workshop. Identify where bringing the backend together can free up your team to improve the shared fitness experience.

‍