I am trying to make an online teacher-doubt solving MERN application.
The workflow is as follows:
A user of the app clicks on the "Ask Doubt" button associated with the teacher.
The user makes the payment.
The user is then added to the queue where he/she waits for the doubts of the people ahead of of him/her to be resolved by that teacher. (Edit: The user and the teacher go into a chat room then and the others will wait in the queue)
I also want to display the number of people in the queue already in the queue so that the user can only pay if they have enough time.
I cannot guarantee the average time for each doubt session so I cannot ask the user to come in after some x amount of time.
Also, feel free to suggest some other implementation if u feel my approach isn't good.
Although there might be other ways to solve the problem too, I think using Cassandra as your database might be one of the solutions for you.
You can design the use the teacher id (or name) as your Partition Key and use the timestamp as your clustering column.
When you want to get the details of the person who is next in the queue, u can simply query the first student under that partition (teacher id).
When you are done asking, you can delete then delete the first row.
As I said before, there might be other ways, but this is certainly one of the simpler solutions if scalability is what you want.
Edit: Since you dont have a Doubt Model, you could create a queue model. Which consist of an Array with the user ids.
Then you can do queue.array.length to get the amount of people in the queue. And when they are in the chatroom or finished. You update the array by removing the user from the array.
Related
I will try to keep this as generic as possible using the “order” and “product” example, to try and help others that come across this question.
The Structure:
In the application we have 3 different services, 2 services that follow the event sourcing pattern and one that is designed for read only having the separation between our read and write views:
- Order service (write)
- Product service (write)
- Order details service (Read)
The Background:
We are currently storing the relationship between the order and product in only one of the write services, for example within order we have a property called ‘productItems’ which contains a list of the aggregate Ids from Product for the products that have been added to the order. Each product added to an order is emitted onto Kafka where the read service will update the view and form the relationships between the data.
The Problem:
As we pull back by aggregate Id for the order and the product to update them, if a product was to be deleted, there is no way to disassociate the product from the order on the write side.
This in turn means we have inconsistency, that the order holds a reference to a product that no longer exists within the product service.
The Ideas:
Master the relationship on both sides, which means when the product is deleted, we can look at the associated orders and trigger an update to remove from each order (this would cause duplication of reference).
Create another view of the data that shows the relationships and use a saga to do a clean-up. When a delete is triggered, it will look up the view database, see the relationships within the data and then trigger an update for each of the orders that have the product associated.
Does it really matter having the inconsistencies if the Product details service shows the correct information? Because the view database will consume the product deleted event, it will be able to safely remove the relationship that means clients will be able to get the correct view of the data even if the write models appear inconsistent. Based on the order of the events, the state will always appear correct in the read view.
Another thought: as the aggregate Id is deleted, it should never be reused which means when we have checks on the aggregate such as: “is this product in the order already?” will never trigger as the aggregate Id will never be repurposed meaning the inconsistency should not cause an issue when running commands in the future.
Sorry for the long read, but these are all the ideas we have thought of so far, and I am keen to gain some insight from the community, to make sure we are on the right track or if there is another approach to consider.
Thank you in advance for your help.
Event sourcing suites very well human and specifically human-paced processes. It helps a lot to imagine that every event in an event-sourced system is delivered by some clerk printed on a sheet of paper. Than it will be much easier to figure out the suitable solution.
What's the purpose of an order? So that your back-office personnel would secure the necessary units at a warehouse, then customer would do a payment and you start shipping process.
So, I guess, after an order is placed, some back-office system can process it and confirm that it can be taken into work and invoicing. Or it can return the order with remarks that this and that line are no longer available, so that a customer could agree to the reduced order or pick other options.
Another option is, since the probability of a customer ordering a discontinued item is low, just not do this check. But if at the shipping it still occurs - then issue a refund and some coupon for inconvenience. Why is it low? Because the goods are added from an online catalogue, which reflects the current state. The availability check can be done on the 'Submit' button click. So, an inconsistency may occur if an item is discontinued the same minute (or second) the order has been submitted. And usually the actual decision to discontinue is made up well before the information was updated in the Product service due to some external reasons.
Hence, I suggest to use eventual consistency. Since an event-sourced entity should only be responsible for its own consistency and not try to fulfil someone else's responsibility.
If a user creates a new activity and wants all their followers to see it except 1, how can this be implemented? Do we simply push the activity, and then immediately delete it from the specific follower's timeline feed? This seems like a hack.
https://github.com/GetStream/stream-js/issues/210
this use case hasn't come up before. Why would someone want everyone except one person to see a post? Do they want that person to unfollow them? Are there "rings" or levels of people to choose from when posting? If that's the case, you can create separate feeds with follows to them for those levels (and will likely need to use the TO field as well since fanout only goes 1 level deep).
There's no built in mechanism to specify which feeds to fan out to or which not to. The fanout is intended to happen as fast as possible (milliseconds) so doing those kinds of checks wouldn't be optimal. Your solution to quickly delete from that feed will work.
I'm trying to set up a google wallet payment process for users to purchase an entry into a tournament. In order to do this, the user has to fill out a bunch of information about themselves (name, league player number, contact phone number, etc), and there are some other pieces of data that are implicit, such as a unique identifier for the tournament they're entering.
It seems like there are two ways to accomplish this in Google Wallet, and I'm wondering if I'm missing another, better workflow and/or if one of these two ways is preferred.
Possibility #1
When the user clicks the wallet button, I serialize the form and submit it to my server using ajax. If the form is properly filled out, the server encodes everything about the form into the sellerData field of the JWT, and returns the JWT asynchronously. I then pass this JWT to wallet, expecting to receive it in my postback handler.
The postback handler then constructs the entry using the information from the JWT sellerData field and records it in the database.
This possibility is intuitive to me, and I've implemented it, but I'm running up against the 200 character limit for the sellerData field, since it contains multiple peoples' names, phone numbers, and various other form elements. There's just no room. I don't have a workaround for this, and would welcome thoughts.
This approach has the advantage that nothing is created in my database until payment is successful, but I don't know how to work around the difficulties with representing the entire form in the JWT to get it to the postback handler somehow.
Possibility #2
The user just submits the entry form using the normal web-form submission process, which creates something in the database. Database objects newly created in this way are marked as "unpaid", and are therefore incomplete.
Once the user successfully creates their entry in the database, they are then presented with a second page at which they can pay. This works better because I can now just put the database key for the object they just created into the sellerData field, and not worry about the size limit.
It does have the unfortunate side-effect of having these half-completed objects in the database, as well as running the risk of users not quite understanding the two-step register-and-then-pay process, and forgetting to pay. I'd have to be quite careful and proactive about making sure that users realize that A) it's okay to submit the form with no payment information, and B) that submitting the first form doesn't mean that they're done.
Thoughts?
I think Option 2 is a pretty standard buy flow. Step 1 enter in your information Step 2 confirm your information and pay with Wallet.
The onsuccess callback could then redirect the user to a purchase receipt page.
My consumer mind doesn't see any purchase flow red flags.
I ended up going with option 2, because it was simplest for me and I didn't think it would confuse users.
I missed a third option, though, which is that I could allow people to buy a blank entry form and then fill it out after purchase. I think this might have even been better; it matches the in-person buying experience better and would therefore be more familiar to purchasers, and it avoids the problem of people who think they've registered but somehow didn't realize that they had to pay.
This article explains very clearly how to implement a voting system with MongoDB, and to limit one vote per user and per object.
I have one extra requirement. I need the votes of a given user to be visible for the objects displayed. For example, if I am displaying 20 tweets, and the user has voted on 3 of those tweets, I want those votes to be visible. (For example, using a green up-arrow.)
One solution is to send to the client, for each question, the set of voters. Another solution is to send to the client the set of votes he has cast. I do not see either solution as a scalable one. Any suggestions?
This is something you would do client side.
Once you have the object that contains the vote cound and the array of voters you can check to see if the current user's id is within the array of voters while you iterate over the set of (stories, tweets, what have you)
Does that make sense?
Not a full answer, but a link to a good voting library (fast!!!) for ruby/mongoid. Should be easily portable to node.js, perhaps mongoose.
https://github.com/vinova/voteable_mongo
I need something similar eventually, perhaps we should chat (I am martin_sunset on node.js on freenode)
I've wondered about this for some time now. I'm wondering webforums implement the option to highlight something you haven't read. How the forum knows.
Since most webforums have a function to show you all posts since your last visit, they must save the last time you visited one of their pages in your userdata in the database.
But that doesn't explain how individual topics are still highlighted after you've read just one.
A many to many table connecting a user to a topic/post with flags for read/favorite etc.
Many web forums store a huge list of the last time you looked at each topic you've looked at.
This gets out of hand quickly, but there are mitigations. See Determining unread items in a forum
Keeping track of what posts a visitor has read is of course not that much of a big deal. Since it's highly likely that the number of posts a visitor read will be much less than the posts not read. So, if you know what posts a visitor has read, you also know what posts this visitor didn't read. To make this less computational intensive you'd normally do this only over a certain period of time, say the last two weeks. Everything before that time will be considered read.
Usually, this list of "unread" items only shows changes that have been made since the last time you logged out.
Use the user's last activity date/time to mark items as "unread" (any activity in a topic after that time is marked "unread"). Then store in a Session variable, a list of topic IDs that the user viewed since last login. Combining these two would give you a relatively accurate list of unread topics.
Of course this data would then be lost on log-out or session expire and the cycle would start again without sacrificing an unnecessary amount of SQL queries.
On the custom forum I used to work with, we used a combination of your last visit time (updated every time you viewed another page - usually cookied), and a "mark read" button on each topic that added a date/time value to a SQL table containing your UserID, the TopicID and the Date/Time.
Thus to view new topics we would look at your last visit date and anything created after that point in time was a new topic.
Once you entered a topic any topic you had clicked "mark read" on would only show the initial topic and then any replies with a date/time added after you clicked the mark read button. If you have fewer viewers and performance to spare you could basically set it up to add an entry to the table for every topic the user clicks on, when they click on it.
Another option you have, and I have actually seen this done before in a vBulletin installation, is to store a comma separated list of viewed topic ids client-side in a cookie.
Server-side, the only thing stored was the time of the user's previous visit. The forum system used this in conjunction with the information in the user's cookie to show 'as read' for any topic where either
Last modified date (ie last post) older than the user's previous visit
Topic ID found in the user's cookie as a topic the user has visited this session.
I'm not saying it's a good idea, but I thought I'd mention it as an alternative - the obvious way to do it has already been stated in other answers, ie store it server-side as a relation table (many to many table).
I guess it does have the advantage of putting less burden on the server of keeping that information.
The downsides are that it ties it to the session, so once a new session is started everything that occurred before the last session is considered 'already read'. Another downside is that a cookie can only hold so much information, and a user may view hundreds of topics in a session, so it approaches the storage limit of the cookie.
One more approach:
Make sure your stylesheet shows a clear difference between visited and non-visited links, taking advantage of the fact that browsers remember visited pages persistently.
For this to work, however, you'd need to have consistent URLs for topics, and most forum systems don't tend to do this. Another downside to this is that users may clear their history, or use more than one browser. This therefore puts this measure into the 'not highly reliable category'; you would probably just do this to augment whatever other measure you are using to track viewed topics.