SOLUTION REVIEW

Review: Strava

Record routes offline, reconcile idempotent uploads, and publish versioned privacy-safe activity and segment views.

A AceYourInterviews editorial · 30 min study

Clarify this prompt before choosing components

Ask the highest-impact questions first, agree on priorities, and record the interviewer’s answers. If a detail is unspecified, state an assumption and explain which decision depends on it. The numbers in this worked lesson are exercise assumptions, not company facts.

Ask the interviewer	Why the answer changes the design
Activity recording, segments, leaderboard or social feed first?	Separate private source activities from derived competitive views.
GPS gaps, duplicate uploads and activity edits?	Stable activity identity, validation and revisioned recomputation are needed.
Privacy zones, leaderboard eligibility and late corrections?	Derived projections must withdraw ineligible data and expose freshness.

Use the Interview Playbook for the shared 45-minute sequence and fresher, intermediate, senior and staff evidence. Start with one complete operation. Extend the answer with the failure/recovery traces below, then defend a workload-specific alternative and a measurable rollout. Scope and evidence matter more than a large component list.

Strava: Understand the building blocks

Choose a mechanism because it satisfies a requirement. These explanations describe the exercise design, not undisclosed implementation choices at the named company.

Strava: Quick vocabulary

Term	Meaning and role in this exercise
API: Application Programming Interface	The contract for requests, responses and errors between components. An API route does not itself enforce every business invariant.
CPU: Central Processing Unit	General-purpose compute whose time/concurrency must be bounded for judging, processing or encoding.
GPS: Global Positioning System	A source of location observations. Device reports can be delayed/noisy; validate sequence, age and accuracy under the exercise policy.
URL: Uniform Resource Locator	Names a resource and access location. Normalize carefully and do not trust an imported address as a safe server fetch destination.

Strava: Object storage, chunks and content hashes

What it means: Object storage keeps large named byte objects. Chunking divides a file into smaller pieces; content hashes identify or verify bytes under a specified hash protocol.

Why this problem needs it: Offline samples should upload in bounded resumable units.

How to use it: Upload to a versioned session, verify all required chunks and checksums, then atomically publish metadata referencing the complete manifest.

Example in this design: Retry chunks 12–14 with stable identities rather than adding duplicate samples.

When it fits: Useful for resume, reuse or large bytes that should not flow through metadata database rows.

Alternative and limits: Whole-file upload is simpler for small files. A hash match or completed upload does not authorize publication or resolve a concurrent file revision.

Strava: Projection and materialized view

What it means: A projection is a derived read model built from authoritative facts; it improves a particular read path and can be rebuilt.

Why this problem needs it: Distance and summaries are derived from retained activity facts.

How to use it: Consume versioned facts with replay-safe updates, expose a watermark/revision, and compare or rebuild from the authoritative history.

Example in this design: Processor v4 supersedes v3 under a declared algorithm/version policy.

When it fits: Useful when read shapes or volume justify duplicating computation/state.

Alternative and limits: Read authoritative rows directly for a simpler strongly current baseline. A stale projection must not grant revoked access or decide a strict inventory transition.

Strava: Spatial index and exact distance filter

What it means: An index that groups positions so a nearby query examines a bounded candidate set instead of scanning every location.

Why this problem needs it: Nearby routes/segments need candidate geography and privacy filtering.

How to use it: Search cells or bounding regions that intersect the requested radius, including boundaries, then compute exact distance and current eligibility for candidates.

Example in this design: A public nearby result must not reveal a hidden start location.

When it fits: Useful when frequent nearby queries make a full scan too expensive.

Alternative and limits: A small dataset may need only a scan. Geohashes, quadtrees and spatial database indexes have different update, precision and query costs. Proximity does not imply availability.

Mechanism reference

Strava: Access Control List (ACL) and current authorization

What it means: An ACL records which principals may perform specified actions on an object. Authorization evaluates the applicable current policy for this request.

Why this problem needs it: Derived summaries and public views can outlive privacy changes.

How to use it: Authenticate the caller, evaluate object/tenant membership and permission version at the required disclosure/mutation boundary, and declare caching/revocation behavior.

Example in this design: Recompute or deny under the current policy rather than exposing an old public projection.

When it fits: Needed when object access can change while connections, projections or cursors remain alive.

Alternative and limits: Capabilities/signed grants can fit a bounded expiry policy. A valid cursor, cached candidate or open socket is not permanent permission.

Product journey and correctness contract

A runner taps Start outdoors, records for an hour, pauses at a crossing, resumes, and saves while the phone has no signal. Later, the phone reconnects and uploads the route. The athlete expects distance and elapsed time to remain available during capture; the server must accept retries without duplicating points, refuse to publish an incomplete track, and keep private coordinates out of public activity and segment views.

The device is authoritative for the capture log until it has durably uploaded every chunk and the server acknowledges the final manifest. The server is authoritative for the finalized raw track and current privacy. Summaries and segment efforts are derived records tied to both source and algorithm versions. A delayed worker may not overwrite newer work or restore an effort after a privacy change.

The core journey is start, sample, pause/resume, finish, synchronize, then view history. Live friend tracking, turn-by-turn navigation, social feed ranking, and training plans are extensions. We can lose a network connection without losing captured data. We cannot promise perfect GPS, exact real-world distance, or deletion of a route someone already downloaded.

Requirement	Contract	Verification
R1 Capture	Start, pause, resume, and finish form a legal state machine. Local capture persists before network work.	V1–V2
R2 Stats	Device estimates distance/time from validated samples and explicit pauses; quality limits are visible and versioned.	V3
R3 Sync	Chunk keys are stable; identical retries are no-ops; changed retries conflict; finalization waits for every chunk and expected sample.	V4–V5
R4 History	Finalized activities have durable summaries and owner-scoped history.	V6
R5 Sharing	Every response checks current visibility or an active grant; private raw tracks never enter public projections.	V7
R6 Rankings	Segment efforts are versioned, replay-safe projections with deterministic ties and removal semantics.	V8

Data model and access paths

Entity	Primary identity and important fields	Invariant / access path
Activity	activity_id, athlete_id, client_activity_id, started_at, state, privacy, version	Unique athlete plus client_activity_id makes a lost create response safe to retry. Owner history is indexed by athlete and descending start time.
TrackChunk	activity_id plus sequence, checksum, sample_count, immutable object key	Unique sequence; identical retry is a no-op, different bytes at the same sequence return conflict.
Sample	activity_id, sequence, point_index, timestamp, latitude, longitude, optional altitude	Ordered by sequence and point index; timestamps must increase. Protected raw input supports reproducible processing.
FinishManifest	activity ID, expected chunk/sample counts, end timestamp, pause intervals, digest	Immutable after first accepted finish request. Finalization requires complete sequences 1 through N and exact sample count.
Summary	activity_id, source_version, algorithm_version, distance, elapsed, moving, paused, quality counts	Derived output is idempotent for a version pair. Current pointer advances only to a valid newer pair.
ShareGrant	activity_id, viewer_id, grantor, created/revoked timestamps	Exists only when policy permits; every read rechecks current activity privacy.
Effort	activity_id, segment_id, source_version, algorithm_version, crossings, duration, eligibility	One current contribution per activity/segment. A rebuild replaces prior contribution; privacy or deletion removes it.

Chunk storage is partitioned by activity so a worker can replay one route without scanning an athlete's history. Very large routes can use immutable objects with checksummed metadata rows; the manifest and current activity version remain transactional database state. Avoid one mutable “upload complete” bit: it cannot explain which chunk is missing or distinguish a retry from changed content.

API contract

Operation	Request	Success and retry behavior
POST /activities	clientActivityId, start time, capture metadata, privacy	201 with activityId and state; same athlete and ID with same request returns same result; changed request returns 409.
PUT /activities/{id}/chunks/{sequence}	bounded sample batch and checksum	200; same bytes are idempotent; same key with different bytes is 409; checksum mismatch is 422.
POST /activities/{id}/finish	expected chunk count, sample count, end time, pause intervals	202 awaiting_chunks with missing sequence list until complete; exact retry is safe; changed manifest returns 409.
GET /activities/{id}	authenticated owner or authorized viewer	Returns only fields allowed by current visibility; unauthorized response is consistently 403 or concealed 404.
GET /athletes/{id}/activities?cursor=…	authenticated owner or authorized history viewer	Stable descending cursor pagination; cursor binds owner and sort key, never an offset into a changing list.
PUT /activities/{id}/privacy	visibility and expected activity version	Conditional update; returns new version. Private transition revokes grants and removes public projections before serving.

Authentication identifies the athlete; a device-provided athlete ID is never trusted. Cap request bytes, samples per chunk, chunks per activity, and finish-manifest size. Bound decompression before parsing. A rate limit protects ingestion, but a rate-limited offline client retains its local queue and retries with backoff rather than deleting data.

Capacity worksheet

The public interview outline cites a scale of roughly 10 million concurrent activities. For a planning estimate, assume one GPS sample per second and 32 compressed bytes per sample. That is 10 million samples/s × 32 B = 320 MB/s, or about 1.15 TB/hour before replication, indexes, metadata, and protocol overhead. This is illustrative, not measured production workload. If actual cadence is 0.2 Hz, payload rate is one fifth; if points average 80 bytes on the wire, it is 2.5 times larger.

At one sample per second, a two-hour workout contains 7,200 points and about 230 KB at the assumed encoding. Batch 30 seconds at a time: each chunk has about 30 points and 960 bytes before headers. Ten million active uploads then produce about 333,000 chunk requests/s at that cadence. Batching reduces request overhead but increases unsent work after a device crash; persist each batch locally before acknowledging capture progress.

The cost decision is local durable storage plus append-oriented object writes, not a synchronous database transaction per GPS point. Partition chunk metadata by activity ID and distribute upload gateways independently from CPU-heavy route processing. Queue depth and age determine whether summaries remain within a one-minute target; adding upload nodes does not fix a saturated geometry processor.

Memory is also bounded by batching. If a decoded point averages an assumed 160 bytes, a 30-point chunk is about 4.8 KB in worker memory. Keeping 512 chunk requests in flight uses about 2.5 MB of point data per gateway process, before request buffers and runtime overhead. A two-hour route is about 1.15 MB at that decoded size; processors should stream chunks and cap concurrent activities instead of loading an unbounded backlog into RAM.

Design step 1 — Record samples locally so capture survives network loss

Create a local activity row before starting GPS capture. Append timestamped samples and state markers (START, PAUSE, RESUME, FINISH) to a durable device log. Assign monotonically increasing sample and chunk sequences on the device. A UI can show current distance immediately; network calls run from an upload worker and never gate recording.

Each local chunk is immutable after checksum creation. If the process restarts, read the last committed sequence and resume from it. If device storage is full, surface a clear stop condition before silently discarding route points. If GPS permission is revoked, keep the activity and mark the gap rather than inventing coordinates. A device clock correction may cause timestamps to regress; flag it and retain monotonic capture order separately from wall-clock time.

The device persists the capture log and queues bounded chunks for later upload. — Local capture is durable before networking; upload retries do not own the recording lifecycle.

Design step 2 — Compute live distance and time on-device

For consecutive valid GPS samples, use haversine distance on a spherical Earth. Given latitude/longitude in radians, a = sin²(Δφ/2) + cos(φ1)cos(φ2)sin²(Δλ/2), and d = 2R asin(√a), with R approximately 6,371,009 m. Normalize longitude difference across the antimeridian. Reject invalid coordinates and flag a segment when its time gap exceeds a configured threshold or implied speed exceeds a plausibility limit. Preserve all raw points; cleaning parameters belong to a versioned summary, not destructive edits.

Elapsed time is finish_time minus start_time. Paused duration is the sum of validated pause intervals clipped to the activity window. Moving time is elapsed minus paused time, while distance sums accepted moving segments only. A point pair that spans a pause is not joined: otherwise a straight line through a stopped interval creates false distance. When the final GPS fix predates the finish action, elapsed time still ends at the explicit finish timestamp.

Accuracy competes with battery. One-Hz GPS gives finer route shape and responsive pace but consumes more power and creates more upload bytes. A device can adapt cadence when stationary or when horizontal accuracy is poor, but it must record cadence/quality metadata and avoid presenting interpolated points as observations. Report observed sample count, rejected segment count, and accuracy bands so users can distinguish estimates from ground truth.

Pause and resume markers separate elapsed time from moving time and prevent distance across a stop. — A pause is a first-class interval, not an inference from zero speed.

Design step 3 — Upload sequenced chunks and reconcile a final manifest

The upload worker sends chunks independently and can retry them in any order. The server verifies checksum and sequence identity, stores the chunk durably, then acknowledges it. A duplicate with equal checksum and sample count is successful but does not append data twice. A duplicate sequence with different content is a conflict requiring client recovery, not last-write-wins replacement.

Finish is a declaration of expected completeness, not a claim that all bytes arrived. The server records a manifest containing N expected chunks, exact sample count, end time, pause intervals, and digest. It reports missing chunk numbers and waits. A late missing chunk can arrive; a chunk beyond N cannot. Once every sequence from 1 through N exists and sample count matches, one conditional transaction moves the activity from awaiting_chunks to finalized and emits a processing event through an outbox. A worker never sees a partial track as final.

A final manifest exposes missing chunks; late chunks close the gap before finalization. — Out-of-order retries are harmless, but the missing sequence remains visible and blocks finalization.

Workers load the immutable finalized track and calculate an output for the pair (source_version, algorithm_version). A conditional compare-and-swap publishes only if the activity is still at that source version and privacy is still eligible. Reprocessing creates a new algorithm version; it replaces the current pointer and downstream contribution rather than incrementing a count. A transactional outbox makes processing and projection retries discoverable after crashes.

History reads use the athlete/time index and a stable cursor. Private is the default. Friends visibility requires an active grant or a clearly defined current friendship predicate. Every API, map tile, download, search index, and leaderboard read applies current authorization. A hidden map marker does not protect coordinates returned from the API. Privacy-zone clipping transforms the public route before indexing and serving it; raw samples stay in protected storage. Changing the zone or visibility increments the source/privacy version and invalidates dependent projections. Previously downloaded routes cannot be recalled.

Segment matching begins with spatially indexed candidate segments near the route, then checks ordered geometry and direction with a documented tolerance. For a teaching segment on the x-axis from 0 m to 1,000 m, a route has samples (-10 m, t=0 s), (10 m, t=2 s), (990 m, t=100 s), and (1,010 m, t=102 s). Linear interpolation crosses the start at 1 s and finish at 101 s, so effort duration is 100 s. Reverse travel does not match a directed segment. Sparse samples with a large gap cannot prove that the runner followed the segment; reject or mark uncertain rather than inferring a pass from endpoints alone.

Versioned summaries feed privacy-filtered history and replay-safe segment projections. — Summary and leaderboard records are derived views with explicit source and algorithm versions.

Deep dive — Offline conflict and recording authority

The phone owns the capture sequence while offline. The server owns acceptance of immutable sequence keys after upload; it does not merge two divergent payloads under the same key. If an athlete edits metadata before sync, send a separately versioned metadata patch with an expected version. Raw GPS samples are not rewritten to resolve metadata conflicts. If an upload retry reaches a different server region, the same unique key and checksum produce the same result.

The finish race is handled by keeping awaiting_chunks distinct from finalized. A worker may finalize only after a durable manifest and complete range check. If a worker crashes after writing summary output but before acknowledging the queue message, its retry sees the same version key and returns the existing result. If a newer activity or privacy version exists, an older job is stale and cannot publish. Exactly-once effect is an application property built from durable identity and idempotent writes; the queue itself may deliver more than once.

Deep dive — GPS noise and missing samples

GPS jitter can make a stationary runner appear to move. A filter can reject impossible speed, poor accuracy, and large time gaps, but thresholds are product choices and must be versioned. Do not bridge a long missing interval with a straight line: the runner may have turned or stopped. Preserve flagged segments and compute a transparent estimate from accepted intervals. If a correction changes distance, keep the prior algorithm version for audit and publish the newer one atomically.

Coordinate interpolation for a segment crossing is acceptable only for a sufficiently short sample interval and a route within the configured corridor. The matching algorithm should require start-before-finish ordering, direction, maximum gap, and intermediate geometry evidence. A spatial cell index only narrows candidates; exact geometry decides whether a route qualifies. Privacy-zone clipping must precede public geometry indexing, and a segment effort that reveals a protected start/end can be suppressed even when the route map itself is clipped.

Deep dive — Scale, batching, and replay-safe rankings

At the illustrative 320 MB/s peak, retain bounded per-activity chunks and queue lightweight processing references rather than copying full payloads through every service. Partition raw objects by activity and time; batch writes at the device and apply server backpressure at chunk boundaries. Keep a maximum activity duration, sample count, request size, and retry age. Expired upload sessions can resume through a signed, owner-scoped token; the token is not a public activity URL.

For each segment, maintain one eligible best effort per athlete, selected by duration, then finish time, then stable athlete ID. A late replay with the same event identity is a no-op. A new source or algorithm version replaces the previous activity contribution. If the fastest effort is deleted or becomes private, recompute that athlete's best from remaining eligible efforts; subtracting a single global counter is insufficient. Leaderboard pages use a stable generation/cursor, or explicitly document that results may shift as projection updates arrive.

An effort and privacy event race is fenced by activity and algorithm versions. — A projection job commits only against the current activity version and eligibility.

Failure verification trace

Use a concrete offline scenario: the device records chunk 1 and chunk 3, then sends finish(expectedChunks=3, expectedSamples=3, endTime=102). The server returns missingChunks=[2]; finalization leaves the activity in awaiting_chunks. The device reconnects and sends chunk 3 again, then chunk 2. The identical chunk 3 retry is a no-op; chunk 2 closes the gap. Finalization succeeds only when all three chunk keys exist and sample count is exactly three. Replaying finish and processing messages does not create duplicate points, summary rows, or leaderboard entries.

Case	Expected result	Model/test evidence
V1 Start response is lost	Same athlete/client ID returns same activity.	test_limits_client_identity_and_privacy_are_validated
V2 Pause and resume	Paused time is excluded; no distance crosses pause.	test_pause_resume_markers_exclude_paused_time_and_distance
V3 GPS gap or speed spike	Preserve samples, flag segment, exclude its distance.	test_gps_gap_and_speed_spike_are_flagged_not_counted
V4 Chunks arrive out of order and retry	Missing range is explicit; equal retry is a no-op; changed bytes conflict.	test_out_of_order_chunks_are_durable_and_identical_retry_is_noop; test_same_chunk_key_with_different_bytes_conflicts
V5 Finish races late chunk	No partial finalization; late gap fill permits finalization.	test_finish_race_reports_missing_range_and_never_publishes_partial_track
V6 Summary retry or stale worker	Equal version replay is idempotent; older source is fenced.	test_summary_retry_is_idempotent_and_algorithm_version_replaces; test_summary_requires_finalized_activity_and_fences_stale_versions
V7 Privacy changes during reads	Private transition removes grants and prevents later access.	test_private_transition_revokes_grants_and_authorization
V8 Effort replay/privacy race	One current effort; stale private result cannot restore ranking; ties and deletion are deterministic.	test_leaderboard_effort_replay_does_not_duplicate_and_new_algorithm_replaces; test_stale_effort_after_privacy_change_cannot_restore_leaderboard; test_leaderboard_ties_are_stable_and_deletion_recomputes_athlete_best

Final architecture and requirement trace

Strava final architecture: capture log, upload reconciliation, immutable track, versioned processing, history and projections. — The architecture has one capture authority and separates rebuildable outputs from privacy-checked reads.

Requirement	Design owner	Observable evidence
R1 Capture	Device log and capture state machine	Local sequence continuity, pause markers, storage-full and permission states
R2 Stats	Versioned local and server summary	Distance, elapsed/moving/paused time, accepted/rejected segment counts
R3 Sync	Unique chunk keys and immutable finish manifest	Missing sequence count, checksum errors, retry conflicts, finalization age
R4 History	Activity store and owner/time index	History latency, cursor stability, durable finalized summary
R5 Sharing	Authorization and privacy transformation	Denied reads, grant revocation age, public-projection version lag
R6 Rankings	Versioned effort projection	Rebuild lag, stale-job rejects, per-athlete replacement and deletion reconciliation

Failure table

Failure	Detection	Recovery	User-visible behavior
Device offline or app restart	Local queue age and sequence gap	Resume immutable chunk upload with backoff	Recording continues; sync status is pending
Missing or corrupt chunk	Manifest gap or checksum failure	Request exact missing sequence; replace local corrupt copy only after verification	Activity remains saved locally and is not fully published
Worker outage	Queue age and oldest finalized activity	Replay outbox references from raw storage	Summary is pending; raw activity stays safe
GPS quality failure	Accuracy, gap, speed, and rejected-segment metrics	Recompute with a new documented algorithm version	Estimate is marked with quality limits
Privacy update races projection	Version mismatch or stale projection	Suppress serving immediately, then rebuild/remove projection	Private activity is inaccessible while cleanup runs
Leaderboard consumer replay	Duplicate event key or source/version mismatch	Idempotent replacement and periodic rebuild	Rank may lag; no duplicate athlete contribution

Operate and recover

Track capture success, upload completion, chunk retry/conflict rates, missing-chunk age, finalization lag, summary queue age, GPS rejection rates by reason, privacy-projection lag, and leaderboard rebuild age. SLIs should distinguish device-side capture from server sync because the network is outside service control. Set admission limits from measured object-store and processor capacity; reject or defer new uploads explicitly instead of creating an unbounded queue.

A recovery drill restores an activity from immutable raw chunks and manifest, recomputes a new algorithm version, compares output and quality counters, then conditionally swaps the current summary and effort projection. Privacy recovery begins with serving suppression and revocation, not with waiting for a background deletion job. Audit access to raw routes and expire device upload tokens.

Practice and review

Prompt: An athlete finishes offline after two pauses. On reconnect, chunks 1 and 3 arrive, chunk 2 is delayed, and a worker receives the finish event twice. Design durable state and explain when the activity can appear in history, when its summary is available, and how a later privacy change affects a segment leaderboard.

Failure follow-up: The final GPS point was at 10:02, the athlete tapped Finish at 10:05, and one pause interval ended at 10:04. What are elapsed time and paused time? What does the final chunk manifest prove?

Review rubric: Full credit identifies the device log as offline capture authority; uses stable sequence/checksum identities; rejects a conflicting retry; keeps the activity pending while a manifest gap exists; computes elapsed from explicit finish and paused duration from bounded markers; pins source/algorithm versions; checks current privacy before publishing; and explains ranking replacement and recovery. The model tests selected invariants, not field GPS accuracy, production durability, or device battery performance.

Operational contract

Area	Decision and signals
SLIs	Chunk-gap age; upload reconciliation lag; GPS-quality rejects; privacy-projection lag; segment-ranking freshness.
Overload limits	Cap chunk size/count, offline upload backlog, processing concurrency, and ranking fanout.
Recovery	Resume by sequence/checksum; finalize only a complete manifest; rebuild projections from immutable raw tracks.
Access controls	Apply privacy filtering before public route/segment projection; restrict precise location to owner and explicit viewers.
Dominant cost	Raw GPS retention, map/route processing, and geographic query compute.

Replay offline samples without changing the activity

Activity a7 stores device sample sequences 10..20. Reconnecting retries 15..20; stable activity/device/sequence identity keeps every sample once. A pause interval from time 100 to 130 is excluded from active elapsed time under the product's rule, while wall elapsed time still includes it. Declare whether distance during pause is counted and treat out-of-order timestamps/GPS quality explicitly.

Contract / pseudocode

stored sequences: 10..20
replayed: 15..20 -> no extra points
wall interval: 90..150 -> 60 seconds
pause: 100..130 -> active time 30 seconds

stored sequences: 10..20; replayed: 15..20 -> no extra points; wall interval: 90..150 -> 60 seconds; pause: 100..130 -> active time 30 seconds — Replay offline samples without changing the activity

Finalization freezes applicable input and algorithm revision; recomputation or anti-cheat correction creates an ordered result revision. Live location sharing has its own current visibility and bounded update path. A leaderboard projector ignores older revisions and replays one accepted result without duplicate rank contributions.

Show answer and explanation

Answer: Client wall-clock order is not enough to establish a valid segment achievement. Retain sequence, trusted timing/quality policy and provenance so suspicious or revised results can be explained and repaired.

Decision review: Strava

Strava: What it is

An activity design captures ordered sensor samples offline, synchronizes verified chunks and derives versioned summaries.

Strava: Why it is needed

Device retries, gaps and noisy samples can change apparent distance or time unless source identity and processing policy are explicit.

Strava: When to use it

Use immutable sample/chunk identities for recoverable offline upload; define whether raw samples, local preview or processed summaries are authoritative for each display.

Strava: How to use it

Pin activity/session identity, sample order, chunk coverage and checksum. Finalize only the declared complete source, then publish derived summaries under the current source and processor versions.

Strava: Compare an alternative

Local previews improve responsiveness but may differ from later corrected summaries. Replacing raw data with a single summary reduces storage but weakens reprocessing and auditability.

Strava: Worked decision exercise

The following inputs and policies are original exercise assumptions; they are not measurements or undisclosed company behavior.

Chunks 12–14 upload successfully but the acknowledgement is lost. Replaying those IDs must not double samples. Processor P3 runs source v3 while P4 runs v4; a late P3 result must not replace the current v4 summary.

Strava: Chunks 12 through 14 are retried after a lost reply; Same chunk IDs do not add samples twice; P4 source v4 becomes current before P3 finishes; Reject P3 publication; revisit privacy-derived outputs — Strava: a concrete state and recovery trace under the exercise assumptions.

Can a privacy-zone change be applied only to the public map thumbnail?