Engineers at Expedia Group write about software delivery, testing, code review, machine learning and geo data systems.
HN commenters link its Monte Carlo forecasting post as an example of simulating past team behavior to give a delivery range; other comments cite its testing and design advice.
> However, if this design is used as a local cache over shared memory for a high throughput system (trading? ML feature store?) the scalability can be handy.
In that case, one might be concerned about the hit rates. While FIFO & LRU have been shown to work very well for a remote cache, especially in social network workloads, it is a poor choice in many other cases. Database, search, and analytical workloads are LFU & MRU biased due to record scans. I'd be concerned that Segcache's design is not general purpose enough and relies too heavily on optimizations that work for Twitter's use cases.
Unfortunately as applications have dozens of local caches, they are rarely analyzed and tuned. Instead implementations have to monitor the workload and adapt. Popular local caches can concurrently handle 300M+ reads/s, use an adaptive eviction policy, and leverage O(1) proactive expiration. As they are much smaller, there is less emphasis on minimizing metadata overhead and more on system performance, e.g. using memoization to avoid SerDe roundtrips to the remote cache store. See for example Expedia using a local cache to reduce their db reads by 50% which allowed them to remove servers, hit SLAs, and absorb spikes (at a cost of ~500mb) [1].
[1] https://medium.com/expedia-group-tech/latency-improvement-with-in-memory-caching-using-caffeine-34713ec77446
Yes! This can't be repeated enough IMO
> Terminology
> The test that hits the endpoint is commonly referred to as an “integration test”, and the other test is commonly referred to as a “unit test”.
> Kent Beck (the originator of test-driven development) defines a unit test as “a test that runs in isolation from other tests”. This is very different from the definition of a unit test as “a test that tests a class/method in isolation from other classes/methods”. The test that hits the endpoint satisfies the original definition.
> But it doesn’t really matter if you want to call a given test an “integration” test or a “unit” test. The point is the test fails when something breaks and passes when something is improved. If it does the opposite, it’s not a good test.
https://medium.com/expedia-group-tech/test-your-tests-f4e361818720
Forecasting looks like this: https://medium.com/expedia-group-tech/monte-carlo-forecasting-in-software-delivery-474bb49cb3f9
It’s running through simulations based on previous team behavior to give a range.