Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Im refactoring a monolith to microservies. I am not clear on data responsibility and access with microservices. From what I read we should take vertical slices.
So each service should be responsible for its own UI/WebAPI/DB, with distinct responsibility.
For example if I had a monolith shopping cart app, I could break it into the following services:
CustomerAccount
ProductSearch
ProductMaintenance
ShoppingCart
Ordering
What do I do with shared data, how do I determine what part of the system is responsible for it?
e.g. In my shopping cart example...
The CustomerAccount, ShoppingCart and Ordering need to know about the Customer data.
The ProductSearch, ProductMaintenance, ShoppingCart and Ordering need to know about Product Data data.
The Ordering will update the number of products available, but so should the productMaintenance.
So should the services send messages back and forth to get data from one another,
or should there be a master service, which handles the communication/workflow between services
or should they read/write from a common database
or something else?
This seem little late to answer but it may be good for future use.
Microservice calling another Microservice is totally fine, what you should be aware of is in case the communication between Microservices becomes to chatty than you should look at a different solution(maybe duplication of data across services, or have it with in same service).
In your case I would build a separate services for each entity that you call for common and reevaluate the situation afterwards.
Hope this helps
Best regrads
Burim
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 months ago.
Improve this question
I confused this Events,Listeners and observers in laravel
Observers and events do not behave at all like each other
Observers are basically predefined events that happen only on Eloquent Models (creating a record, updating a record, deleting, etc). Events are generic, aren't predefined, and can be used anywhere, not just in models.
Observers:
An observer watches for specific things that happen within eloquent such as saving, saved, deleting, deleted (there are more but you should get the point). Observers are specifically bound to a model.
Events:
Events are actions that are driven by whatever the programmer wants. If you want to fire an event when somebody loads a page, you can do that. Unlike observers events can also be queue, and ran via laravel's cron heartbeat. Events are programmer defined effectively. They give you the ability to handle actions that you would not want a user to wait for (example being the purchase of a pod cast)
The documentation does a very good job covering these.
Reference Taken From : https://www.scratchcode.io/laravel/difference-between-events-and-observers-in-laravel/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I am working on a ticketing system using Laravel. Are there any known techniques to prevent double bookings in a ticketing system.
Scenario
Ticket A has only 6 tickets available, User A comes in and adds 4 into their basket. I intend to make an API call to the database to deduct 4 from the available ticket number and then start a 10 minute timer within which User A must complete payment or else the tickets will be added back to the database.
However, a big flaw in my method is this: if the user simply closes the window, I have no way of checking the elapsed time to re-add the tickets back. Any ideas or other known techniques that I can make use of?
I already took a look at this question but still run into the same issue/flaw
Locking while accessing the Model would solve most of your worries and don't let core business logic being enforced on the front end.
Use database transactions to secure only one row is modified at a time and check that the ticket amount is available or else fail. This can produce database locks, that should be handled for better user experiences. There will not be written anything to the database, before the transaction is executed without any errors.
Thorwing the exception will cancel the operation and secure the operation to be atomic.
$ticketsToBeBought = 4;
DB::transaction(function ($query) {
$ticket = Ticket::where('id', 'ticket_a')->firstOrFail();
$availableTickets = $ticket->tickets_available;
$afterBuy = $availableTickets - $ticketsToBeBought;
if ($afterBuy < 0) {
throw new NoMoreTicketsException();
}
$ticket->tickets_available = $afterBuy;
$ticket->save();
// create ticket models or similar for the sale
});
This is a fairly simple approach to a very complex problem, that big companies normally tackle. But i hope it can get you going in the right direction and this is my approach to never oversell tickets.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Our usecase is that multiple assets send different types of data (let's say status, temp and data) to a MQTT broker. Because message brokers are very good at routing, handling topics, etc., the assets publish each type of data to a dedicated topic:
status messages > status topic > e.g. /asset/123/status
temp messages > temp topic > e.g. /asset/123/temp
data messages > data topic > e.g. /asset/123/data
Now our question came up, how the subscriber should handle the different topics. We therefore use the default Paho client via SpringIntegration. In our minds, there are two possible solutions to this:
Solution 1
One Paho client subscribes to all the respective topics. Now the actual routing (which callback for which type of data) must be done in the backend itself.
Solution 2
One Paho client for each topic. So the actual routing is done at the message broker and no routing logic must be done in the backend anymore. The clients simply call their callback and the backend just focuses on its domain logic (not on the routing of topics).
Best Practise?
Now our question is, are there any best practices concerning this question? From our perspective, routing is the job of the message broker, because this is what is is designed for. So the routing logic should not be within the backend. That's good because the backend can now concentrate on its own domain logic. But for this, we would need to have n clients, with n being the amount of different data types. This could possibly let the connections explode when, at some point of time, having more and more message types and therefore more and more topics.
Are there any best practices, benchmarks or (anti) pattern covering this topic?
I've implemented more Solution 2 than Solution 1 in similar cases. As you rightly point out, the backends can just focus on their singular use cases, and not have to worry about the others.....if that is really the case. If at some point down the road, you need /status along with /data, then that becomes a problem you would not have with Solution 1. Solution 2 takes more compute resources, but is usually faster (depending on your MQTT broker and what your solution is running on.) Solution 2 is also better for things like troubleshooting and bugs that cause crashes -- A crash only affects the one domain, not all of them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
What is event-driven programming and has event-driven programming anything to do with threading? I came to this question reading about servers and how they handle user requests and manage data. If user sends request, server begins to process data and writes the state in a table. Why is that so? Does server stop processing data for that user and start to process data for another user or processing for every user is run in a different thread (multithread server)?
Event driven programming != Threaded programming, but they can (and should) overlap.
Threaded programming is used when multiple actions need to be handled by a system "simultaneously." I use simultaneously loosely as most OS's use a time sharing model for threaded activity, or at least they do when there are more threads than processors available. Either way, not germane to your Q.
I would use threaded programming when I need an application to do two or more things - like receiving user input from a keyboard (thread 1) and running calculations based upon the received input (thread 2).
Event driven programming is a little different, but in order for it to scale, it must utilize threaded programming. I could have a single thread that waits for an event / interrupt and then processes things on the event's occurrence. If it were truly single threaded, any additional events coming in would be blocked or lost while the first event was being processed. If I had a multi-threaded event processing model then additional threads would be spun up as events came in. I'm glossing over the producer / worker mechanisms required, but again, not germane to the level of your question.
Why does a server start processing / storing state information when an event is received? Well, because it was programmed to. :-) State handling may or may not be related to the event processing. State handling is a separate subject from event processing, just like events are different than threads.
That should answer all of the questions you raised. Jonny's first comment / point is worth heeding - being more specific about what you don't understand will get you better answers.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Where does session handling fit in the overall concept of MVC? The model or the controller?
The purpose of the SessionState is to persist data about the user's session from one HttpRequest to the next. In some cases this is an an easier solution than manually implementing cookies or creating a data store for session info and passing an identifier. MVC's way of doing this is to use TempData, which wraps SessionState. This means it is probably unnecessary to directly access the SessionState unless you are overriding some of the core infrastructure. I think of a Model as being a more metaphorical representation of data. Using session-data in the Model wouldn't seem entirely right, because the model is probably representing some business logic, that SessionState would unnecessarily complicate. System.Web.Mvc provides a lot of mechanisms that allow us to maintain state without having to use the HttpContext directly. These mechanism are contained as properties of the ControllerContext, the ActionFilter filtering contexts, the ExceptionContext, the AuthorizationContext, the ModelBindingContext, RouteData and ViewContext. They help to separate the bunch of different things that one might store in a session state collection in more logically separated compartments.
TempData is available from the ControllerContext and the ViewContext. This is your access point to session state functionality. If you want to control the handling and writing of this data, and aren't sure where, action filters are a pretty good injection point, because they keep that concern out of the primary business-oriented controller action. This article explores the use of an ActionFilter that automatically persists the model state across requests: http://blog.jorritsalverda.nl/2010/03/10/maintainable-mvc-post-redirect-get-pattern/. I think it may be helpful. The question was not terribly specific... If I did not directly address your question please clarify.
I prefer keeping them at the Controller level or to hide them in custom Action Filters or model binders.
Session state is really a web client concept, I prefer to keep them out of my model for layering sake. Or at minimum I'd wrap it in my own Session or context interface.