Algorithms

𝔇𝔢𝔱𝔢𝔯𝔪𝔦𝔫𝔦𝔰𝔱𝔦𝔠 𝔰𝔦𝔪𝔲𝔩𝔞𝔱𝔦𝔬𝔫 𝔱𝔢𝔰𝔱𝔦𝔫𝔤 deterministic: of or relating to a process or model in which the output is determined solely by the input and initial conditions, thereby always returning the same results ( stochastic ): The algorithms are simple and deterministic, so the results are predictable and reproducible. Example based testing Example based testing works fine for simple cases where there’s only a small number of actions that matter. let%test_unit "append entries: truncates the log on entry conflict" = let storage = make { dir = Test_util.temp_dir () } in (* Leader adds some entries to the replica's log. *) append_entries storage (last_log_index storage) [ { term = 1L; data = "1" }; { term = 2L; data = "2" }; { term = 3L; data = "3" }; ]; (* Another leader overrides the replica's log. *) append_entries storage 2L [ { term = 4L; data = "3" }; { term = 4L; data = "4" } ]; assert (entry_at_index storage 1L = Some { term = 1L; data = "1" }); assert (entry_at_index storage 2L = Some { term = 2L; data = "2" }); (* Entry at index 3 has been overwritten. *) assert (entry_at_index storage 3L = Some { term = 4L; data = "3" }); (* Entry at index 4 is new. *) assert (entry_at_index storage 4L = Some { term = 4L; data = "4" }) It becomes way harder to think of and write the examples when the bugs you’re looking for only happen after several events that need to happen in a specific order. ...

As the World Wide Web became more popular all of sudden a server could receive way more traffic than it could handle causing the server to service requests slowly or to not be able to serve them at all1. An intuitive solution to this problem is to cache2 the content served by the servers and allow the clients to fetch content from the caches instead of going to the original server. Several clients communicate with the same cache servers which means that if client 1 fetches the contents for the page example.com, client 2 can fetch the same contents from the cache instead of going to the oirignal server if it decides to visit example.com as well. ...

The problem You are developing an application backed by a database, something happens and then several of your users try to access the same content. Several requests are sent to your backend at almost the same time and your backend hits the database once for each request to fetch the same data. Fetching the data only once If N requests asking for the same data arrive at the backend at around the same time, the backend could hit the database to fetch the data when the first request arrives and force the other requests to await until the data is fetched. When a response to the request sent to the database arrives at the backend with the data, the data can be shared with the requests that are waiting for it. ...

What is a log A log is just a immutable sequence of records wih strong ordering semantics that can be used to provide durability, replication and to model consensus. It is usually a 0 indexed file that new entries are appended to because expensive disk seeks can usually be avoided when appending to a file1. Not to be confused with the type of logs most people are used to: application logs that are meant to be read by humans although application logs are a degenerative case of the log we are talking about2. ...

Intro Token bucket is an algorithm that can be used to rate limit requests made or received by a service. How it works The algorithm is called token bucket because of the way it works: imagine we have a bucket with x tokens where each accepted request consumes one token from the bucket and a token is added back to the bucket at an interval. A bucket with 1 token that is refilled each second means the service accepts one request per second. ...