rayrutjes

I have to say that I agree with most of your statements. I wouldn't be so radical about either "release fast and introduce bugs" vs "test thoroughly and have longer release cycles".

I think you could definitely see slow release cycles yet introduce bugs. By a matter of fact, I update my desktop software everyday to patch issues. In some environments like in Chrome, extensions get updated automatically. I agree that the end user experience as to be kept in mind.

I'm not encouraging neglecting quality in favour of speed of release. Quality definitely has to be taken into account. It then always comes down to how crucial it is for your code to not be broken, and what the impact of a given change could lead to.

In the end, like always, balance according to the context is key.

(n.b: I am an engineer at Algolia) Algolia's engine computes relevance at indexing time by design, allowing us to deliver optimal search performance at query time. As a result, each new `sort` - by price, by name, by date added - requires several indices containing identical data.

To make this easy to implement, we provide a way to create index replicas, read-only indices that can have different settings from the master index.

When using replicas, every record added to a master index gets also added to the replica index. Same goes for deletion and update operations.

All indexing operations done on replicas are not billed.

By using replicas, you can adjust your calculate by removing the factor of four you included for each index, meaning that 300K*30 days = 9million operations/month. This assumes you update the entire index daily, whereas you could also only update the prices that changed, which would in turn further reduce the number of operations.