tusharRawat has posted 3/4 similar questions about his ecommerce product. They all have lots of detail and describe specific problems but they are all getting close votes and the usual -1 downvote.
I can see arguments for why the db one might be better sent to the db group etc. But that's not why these are getting close votes.
If these questions don't get a good reception we have set such an obscure or high bar for submissions that it really begs the question of what the stack exchange is for.
While I have downvoted only one of the tusharRawat's questions, I do remember being quite annoyed recently when reading three of them. Not sure if my annoyance is representative of the feeling of the persons who downvoted those questions, but anyway, here are my two cents.
The original version finishes by:
What is the recommended industry approach to maintain these counters with good availability and correctness ?
I’m looking for guidance on the standard architectural approach for designing such counter-based limit enforcement at scale.
The first sentence is a clear way for close votes and downvotes. I think no need for further explanation on this point. A recent edit removed this paragraph.
The remaining paragraph now reads:
I’m looking for guidance on designing such counter-based limit enforcement at scale, to maintain these counters with good availability and correctness.
Even with the new formulation, I'm still annoyed. It's way too general. It doesn't show much effort from the author. I know that SE.SE is not StackOverflow, but even here, I would expect the questions to be concrete and focused. The entire question reads like a user story—here's a business requirement, deal with it. That's not what this site is for.
I ended up answering this one. I wasn't annoyed by it at the beginning, but ended up to be pissed off when reading the comments by the OP.
I wasn't annoyed at the beginning, as I often see developers asking a lot of questions and doing premature optimization, in situations where it's so easy to try things.
So I answered exactly that: (1) told that we won't be able to know if there would be performance issues or not, as we don't even know on which hardware it would run, and (2) explained that the OP should just do the simplest thing, measure, and only then try to optimize, if needed.
The OP made an edit by adding a few unhelpful pieces of information (including incomplete specification of hardware), but didn't react to my suggestion to do the actual test.
As I was curious to find out if the thing could work or not, I ended up, a few days later, doing the test myself. As the results were curious, I shared both the results and the source code (immediately receiving a downvote; thanks!), so that OP could play with it.
He didn't. Instead, he started asking for more info, which really annoyed me, as it looked just lazy.
In the context of a previous question, this one makes no sense.
In the previous one, the author came with an unfounded theory of “high contention.” I have shown that there is no high contention, and explained that it would be easy to circumvent anyway. Other answers there also gave some excellent hints as to how deal with a situation where such hypothetical contention presents (including an amazing suggestion by gnasher729).
The author:
Even taken in isolation, the question is still not good:
Can using more advanced transactional techniques—such as Serializable Snapshot Isolation (SSI) or other MVCC-based approaches—significantly reduce contention and improve throughput for this kind of highly contended counter update, while still keeping the updates synchronous in the same transaction?
This is extremely vague. What's “significantly”? Why would we have to browse through all “advanced techniques” (as the OP presented only two examples) and run the benchmark? On what hardware? In what conditions?
Here again, it's not a question. It's a user story that one would write to a developer: “users are unhappy about the performance of that thing; find a way to make it faster.”
Instead, it belongs to the OP to do the benchmark. And if and when there is an actual very concrete problem, then SE.SE (or dba.stackexchange.com) could be helpful.
It could be open ended. For example:
I have [description of the counters thing] that peaks at 650 operations per second when running on [detailed description of hardware topology and software being used]. The profiling shows that the bottleneck is the database—the application servers are underused, while the database nodes are at 100% CPU during the stress tests.
As the project grows, and so the database, one would need in the near future to process 1,500 ops/s.
I tried [name and description of an optimization technique] and [another one]. They, respectively, increased the speed to 700 and 720 ops/s., which is obviously not enough.
Increasing the number of database nodes is not an option, because [business has no money left, as usual].
What else can I try?
Perfectly open ended—answerers could suggest anything, from “hey, you haven't forgot to add indexes, have you?” to some clever techniques (such as gnasher729's “split the counter in ten”). And then, it would belong to OP to do his job—take those suggestions, implement them, do the tests, and come with the results, accepting the answer that brought the most important impact.
I took a look at tusharRawat's 6 undeleted questions:
Does modern isolation techniques help reduce contention for highly contended counter updates? - I think people may be getting hung up on the last question in the paragraph, seeking general approaches used in other systems. But that's an easy enough fix and doesn't seem to invalidate the answer or any comments. If that's not the concern here, I'm really not sure how else to improve the question.
Data modelling for multi-dimensional data - Similar, I think some people may be getting hung up on the last question about industry-standard approaches.
Handling high-throughput counter updates without contention - I'm a bit mixed. It's not a bad question, but I don't think it's necessarily appropriate here. The only answer will come from performance testing, profiling, and perhaps optimizing.
Handling coupon refunds and partial refunds when coupon budgets are enforced via Redis counters - Seems a little broad, but well-received. I can see this being a good high level question to introduce concepts, which can be useful as a starting point for people to find.
Building coupon redemption system with multiple counters - I didn't mod close it, but the only questions here are about "recommended industry approach" and "standard architectural approach" to the problem, neither of which exist. It's not necessarily a good fit.
Lock management for isolation in SAGA Pattern - Good, well-received question.
For two of the questions, it seems like people are not taking basic curation actions and editing the post. If 95% of the post is good and there's a single problematic question tacked onto the end, there's no need to down vote and vote-to-close that question - just edit out that question and maybe do a little other cleanup for the rest of the content. The rest seem either much harder to make a good fit or already well-received.
