Approximation Pattern

in the example where I replace 10 increments with a single increment by 10 write. it is mentioned that this depends on the application, which is good as long as there is a single instance of the application. but in the case if I have multiple instances of my application running, how I will keep track of the state? I mean every instance of my application will have its own counter, so if I have 5 instances of the application behind a round robin load balancer, then this may be hard a little, and when one application instance reaches 10, this mean it is approximately 45 increments.
any suggestion how to a solve this problem other than having common cache?

Each instance will do increment 10 what it has seen 10 operations. So in this case the accuracy is reduced even further since the database will see its first inc-10 at the 46th operations. You may then decide to do inc-5 to double your accuracy.

Doing an inc-2 on a 5 application node gives you more or less the same accuracy and the same number of writes than a inc-10 on a single application node.

in this scenario(having multiple applications load balanced) I feel I may face race condition, am I right? can you discuss this(possibility of race conditions) for the case of $inc and for the case where my update is accumulating strings for example where is $inc not used?

This question is a little bit outside the scope of this course but a good discussion is always welcome.

I do not think the Approximation Pattern, in the context of a load balanced front end application, increases the risk of a race condition. I do not think it would require a different approach compared to an application not using the pattern. Do not forget that your front end might be used simultaneously by multiple clients so what ever race condition may occur at the data back end is the same.

If you come up with an example, we may dig deeper in the subject. I think the curriculum team may let us diverge from the course material as the M320 forum is new and still has low traffic.

1 Like
  1. concurrent increments
    Doing an increment on a counter in a document is an atomic operation in MongoDB.
    This translated into the server reading the value and updating it. If there is a concurrent increment happening, one will fail and the server will redo the failed increment without the client noticing.
    This behavior is implemented in the WiredTiger storage engine in MongoDB and applies to any kind of update. In short, using the $inc function in MongoDB is totally safe.

  2. using many clients with the Approximation Pattern
    If the clients buffer the writes, there will always be a little delta behind the exact value. The more clients, the bigger the difference.
    The alternative is to use a random number generator.
    The client asks for a random number from 0 to 9. Then every time, it gets a β€˜0’ (10% of the time on average), it increments by 10.
    Let’s look at both alternatives with 100 clients, where each client receives 10 operations.
    If the buffer solution, it is not until some clients get their 10th operation that the counter will start changing. By the time each client got 10 operations, the counter will be 1000.
    Using the random generator alternative, if each client gets their first operation at the same time, then ~10 of those clients get a β€˜0’ from the random number generator, then update the counter by 10. The counter value is then ~100, mimicking not using the Approximation Pattern. By the end of each client getting 10 operations, the counter should be very close to 1000. The bigger the value, the smaller the deviation from the real and approximative values, probability wise.