The journeling service is the center of the system. It logs every successful API call, and provides an interface to get changes after a timestamp.
To be extra safe, timestamps should be computed at the server, not client. The journeling serivce keeps reading the journels until it sees the the specified client_device_id, and then return everything seen so far. This can be optimized by keeping last_time for each client_device_id separately.
The journels are cached, since multiple queries likely share a lot of results. Metadata is also cached since it is relatively small and used often.
Each service keeps a soft and a hard timeout when calling underlying services. When some calls experience a soft time out, it notifies the observity service which might provision more resources or adjust the rate limiter to prevent overflowing events. The retry mechanism should be carefully tuned to prevent negative feedback loops.
Latency analysis: metadata is small. file contents are sharded, there is also a hard timeout. The journeling service is also sharded, is a write queue, and protected by rate limiting. They all have bounded response time.
Scalability analysis: web tier is load balanced, metadata, blob storage, and journeling are all sharded and do not have inter-dependency to each other. The databases are also sharded. They all scale linearly.
Reliability analysis: the observity component provisions new instances and adjust rate limiters to prevent overflows. metadata are relatively small and are replicated. blob store is replicated, journel db is replicated