Design an uptime monitor

Question 1

What decides that a URL is due to be checked?

Accepted Answer

Something has to know the time and the schedule. Without it there is no system — a worker that checks whatever it feels like is not a monitor. This is also where you spread the work across the minute instead of firing all 100,000 checks on the same second.

Question 2

A hundred thousand checks are due. How do they reach the workers?

Accepted Answer

A queue between the scheduler and the workers is what lets you add workers to go faster, retry a check that crashed, and survive a restart without losing the queue of due work.

Question 3

What makes the actual HTTP request?

Accepted Answer

Checking is slow and mostly waiting — up to ten seconds each. Separate workers mean you can run many at once and add more when you add customers.

Question 4

Where do 90 days of results live?

Accepted Answer

100,000 checks a minute for 90 days is billions of rows, all written once and read by time range. That shape — append-heavy, queried by window — is what time-series stores exist for.

Question 5

A site goes down at 3am. What happens?

Accepted Answer

The alert path is the product — the checking is just how it finds out. It is worth its own service because it fails differently: an email provider being down must not stop the checks from running.

Question 6

How many checks a second do you need to sustain?

Accepted Answer

100,000 URLs every 60 seconds is about 1,700 checks a second — as long as you spread them across the minute. Firing them all at the top of each minute means 100,000 at once and idle the rest of the time, which is the usual mistake here.

Blueprint — system design