<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Systems on Rik Kisnah - Blog</title><link>https://www.rik-kisnah.ai/teach/systems/</link><description>Recent content in Systems on Rik Kisnah - Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 16 Jun 2026 09:00:00 -0700</lastBuildDate><atom:link href="https://www.rik-kisnah.ai/teach/systems/feed.xml" rel="self" type="application/rss+xml"/><item><title>Design a Token Usage and Limits Service</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-token-usage-and-limits-service/</link><pubDate>Tue, 16 Jun 2026 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-token-usage-and-limits-service/</guid><description>Every request to a language model burns tokens. Somebody has to answer &amp;lsquo;may this user spend more?&amp;rsquo; in a few milliseconds, for personal accounts and for companies with a hundred engineers under one bill, and then record what was actually spent. Design that gate: the entities, the three endpoints, the counters, and the one rule that keeps it from ever blocking the model by accident.</description></item><item><title>Design a Telemetry Platform</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-telemetry-platform/</link><pubDate>Tue, 19 May 2026 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-telemetry-platform/</guid><description>Ingest, process and serve large-scale telemetry to stakeholders with different needs and different sensitivities. Then the follow-up: clients you cannot upgrade emit five names for the same metric. Design the pipeline, then the alias registry that fixes names without ever merging the wrong two.</description></item><item><title>Design a One-to-One Chat</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-one-to-one-chat/</link><pubDate>Tue, 21 Apr 2026 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-one-to-one-chat/</guid><description>One-to-one, text only, web only. That is all the interviewer gives you. Ask for the rest, then design the gateway that finds the recipient, the inbox that survives them being offline, the presence key that expires on its own, and defend Redis Pub/Sub against Kafka out loud.</description></item><item><title>Design an On-Call Paging System</title><link>https://www.rik-kisnah.ai/teach/systems/design-an-on-call-paging-system/</link><pubDate>Tue, 10 Feb 2026 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-an-on-call-paging-system/</guid><description>When the alert fires, wake exactly the right person, make sure someone acknowledges it, and escalate if nobody does. The system that pages must be the last thing standing when everything else is down, so it must not depend on anything else.</description></item><item><title>Design a Quota and Capacity System</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-quota-system/</link><pubDate>Tue, 13 May 2025 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-quota-system/</guid><description>Every customer may use up to N of a thing. The fleet only has M. Track what is used, what is promised, and what is actually free, across a thousand hardware types and a hundred regions, and answer &amp;lsquo;can I have 64 GPUs?&amp;rsquo; in milliseconds without ever saying yes twice for the same GPU.</description></item><item><title>Design a Multi-Region Active-Active Service</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-multi-region-service/</link><pubDate>Tue, 10 Sep 2024 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-multi-region-service/</guid><description>Run the same service in three regions, all taking writes, and survive one region vanishing. The compute part is easy. The data part forces a choice you cannot dodge: who wins when two regions write the same row at the same moment.</description></item><item><title>Design a Distributed Job Scheduler</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-distributed-job-scheduler/</link><pubDate>Tue, 24 Jan 2023 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-distributed-job-scheduler/</guid><description>A to-do list many workers pull from. Run each job once, on time, even when a worker dies half way through. The three words that make it work: lease, retry, idempotent.</description></item><item><title>Design a Web Crawler</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-web-crawler/</link><pubDate>Tue, 16 Aug 2022 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-web-crawler/</guid><description>Start with a few pages, follow every link, and visit the whole web without visiting anything twice or knocking any site over. A giant breadth-first search with a to-do list on disk, a seen-set that fits in memory, and a rule to be nice.</description></item><item><title>Design an Object Store</title><link>https://www.rik-kisnah.ai/teach/systems/design-an-object-store/</link><pubDate>Tue, 09 Nov 2021 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-an-object-store/</guid><description>Put a file in, get the same bytes back ten years later, from any of a hundred million files, after a hundred disks have died. Separate the names from the bytes, cut every file into pieces with spares, and check the pieces forever.</description></item><item><title>Design a Distributed Lock</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-distributed-lock/</link><pubDate>Tue, 11 May 2021 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-distributed-lock/</guid><description>Only one process at a time may touch the thing. Easy on one machine. Across a network, the lock holder can die, pause, or believe it still holds the lock when it does not. Leases, fencing tokens, and the honest answer: a lock cannot make an unsafe operation safe.</description></item><item><title>Design a Log Search System</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-log-search-system/</link><pubDate>Tue, 17 Nov 2020 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-log-search-system/</guid><description>Every server writes thousands of lines a second. An engineer at 3am wants every line containing one request id from the last hour, in under two seconds. Ship, index, tier, and throw away. The hard part is the volume, not the search.</description></item><item><title>Scale From Zero to Millions of Users</title><link>https://www.rik-kisnah.ai/teach/systems/scale-from-zero-to-millions-of-users/</link><pubDate>Tue, 15 Sep 2020 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/scale-from-zero-to-millions-of-users/</guid><description>Start with one machine. Add users until it hurts, fix the one thing that hurts, repeat. Ten rungs from a single box to a sharded, cached, multi-region system, and the reason each rung exists. Learn the ladder once and half the design round becomes recognising which rung you are standing on.</description></item><item><title>Design a Metrics Pipeline</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-metrics-pipeline/</link><pubDate>Tue, 09 Jun 2020 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-metrics-pipeline/</guid><description>Every host writes one line in its diary every minute. A hundred thousand hosts. Get the lines to a place where you can ask &amp;lsquo;which hosts are sad right now?&amp;rsquo; in under a second. The write path must be dumb and cheap. The read path can be clever.</description></item><item><title>Design a Unique ID Generator</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-unique-id-generator/</link><pubDate>Tue, 11 Feb 2020 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-unique-id-generator/</guid><description>Hand out numbers that are unique across a thousand machines, roughly in time order, without those machines ever talking to each other. Pack a timestamp, a machine id and a counter into 64 bits and you are done. Then the clock goes backwards.</description></item><item><title>Design a Safe Deployment System</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-safe-deployment-system/</link><pubDate>Tue, 22 Oct 2019 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-safe-deployment-system/</guid><description>Ship new code to ten thousand machines without taking the site down. One box first, then a few, then a region, with a health check at every step and a rollback that needs no human. The design is the gates, not the copying.</description></item><item><title>Consistent Hashing</title><link>https://www.rik-kisnah.ai/teach/systems/consistent-hashing/</link><pubDate>Tue, 19 Mar 2019 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/consistent-hashing/</guid><description>Put the servers on a clock face. Put each key on the clock face too. Walk clockwise to find its server. Add a server and only the keys just behind it move. This is how caches, key-value stores and load balancers all share work without a reshuffle.</description></item><item><title>Design a Notification System</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-notification-system/</link><pubDate>Tue, 13 Nov 2018 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-notification-system/</guid><description>One event, a million phones. Send the right message on the right channel to the right person, once, and let them turn it off. Fan-out, retries, and the setting everyone forgets: preferences.</description></item><item><title>Design a Distributed Cache</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-distributed-cache/</link><pubDate>Tue, 10 Jul 2018 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-distributed-cache/</guid><description>A shelf by the door where you keep the things you reach for every day. Fast to grab, small, and dangerous when what is on the shelf is no longer true. Eviction, invalidation, and the stampede.</description></item><item><title>Design a Rate Limiter</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-rate-limiter/</link><pubDate>Tue, 20 Mar 2018 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-rate-limiter/</guid><description>A jar of tickets that refills every second. Take one to enter. When the jar is empty, wait. Then the real questions: where does the jar live, and what happens when the jar breaks?</description></item><item><title>Design a Message Queue</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-message-queue/</link><pubDate>Tue, 12 Sep 2017 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-message-queue/</guid><description>A post box between the person who writes letters and the person who reads them. The writer does not wait, the reader does not lose letters, and nobody has to be awake at the same time. Then: what if the post box burns down?</description></item><item><title>Design a Key-Value Store</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-key-value-store/</link><pubDate>Tue, 07 Feb 2017 09:00:00 -0800</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-key-value-store/</guid><description>A giant dictionary spread across many machines. Put a value under a key, get it back later, even when machines die. Partition, replicate, and decide what &amp;rsquo;later&amp;rsquo; means when two copies disagree.</description></item><item><title>Design a Load Balancer</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-load-balancer/</link><pubDate>Tue, 04 Oct 2016 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-load-balancer/</guid><description>A restaurant host who seats guests, checks which waiters showed up, and never becomes the reason the restaurant closes. Layer 4 versus layer 7, health checks, and the part everyone forgets: who balances the balancer?</description></item><item><title>Design a URL Shortener</title><link>https://www.rik-kisnah.ai/teach/systems/design-a-url-shortener/</link><pubDate>Tue, 17 May 2016 09:00:00 -0700</pubDate><guid>https://www.rik-kisnah.ai/teach/systems/design-a-url-shortener/</guid><description>Turn a long web address into a short one and back again. One table, one counter, one cache, one redirect. The whole design is deciding how to make the short code so two people never get the same one, then making the read path fast because reads outnumber writes a thousand to one.</description></item></channel></rss>