![]() ![]() This information needs to be be evicted or updated in the client when it changes. Slack clients statefully cache some information. How can we maintain as much utility as possible in degraded conditions, and exploit good conditions when available? Connections come and go, and vary in their quality and network affinities, even in the middle of sessions. Mobile inherently means unpredictable network conditions. How can we hide this latency? Avoid round-trips? Piggy-back predictable sequels on existing round-trips? Use our more limited edge presence wisely? Many people have a slow round-trip time to our data centers. Slack engineers working on the client-side have rummaged around in the systems toolbox to handle problems like: Since Slack clients run on physical devices, this is impossible, so we must make do. Your Slack client strives to be a consistent, compact, zero latency, searchable replica of all of the files, messages, custom emojis, voice calls, bots, sound effects, etc. The constraints of physical reality make these hopes impossible to realize in every case, but astonishingly many of the common cases can be handled well. Your garbage collector and your kernel’s virtual memory subsystem both strive, in very different ways, to provide the illusion of infinite, fast, volatile memory. Your file system wants to give you infinite, fast, durable storage. Systems problems are rooted in impossible dreams.
0 Comments
Leave a Reply. |