If your data scale is small and only a few people vote (less than 1,000 people), it is unnecessary to worry. Although it will grow, it is okay to simply put it in an array (Pay attention to the size limit of a document in mongodb);
If the number of voters exceeds 1K, and as it continues to grow, reaching a scale of W (ten thousand), become independent early and create another Collection to store the voting records of the post;
If the number of voters reaches W, and the frequency of voting is relatively frequent (or there is malicious manipulation of votes), maybe you should consider using cache to store the IDs of all voters in a centralized cache, and use the cache ( Redis natively supports Set structure) to confirm whether to vote repeatedly, and then synchronize to mongodb regularly in the background;
If the number of voters reaches millions and the frequency of voting is also objective, you must use cache, and it is also a distributed cache cluster to map the IDs of all voters through calculation (you can simply do a mod operation) Go to a certain cache server, and then the processing method is similar to 3;
A process similar to 4: forward the user ID through apache or nginx on the front end of the server, and transfer it to a different application server for processing. The application server also performs distributed horizontal expansion;
PS: What you describe is only a very small aspect of the business scenario. Regardless of whether you use NoSQL or SQL, as the data scale increases, a single machine will inevitably be unable to hold it, and distributed expansion is inevitable. However, it should be noted that the complexity also increases with time. is growing, so you need to choose a plan reasonably based on your data size and technical conditions.
Please confirm your data size before designing: