12

No you shouldn't use level of access as part of the URI. There is already a standard way to separate API by user access, and that's with authorization. All users should access the same endpoints, and based on the authenticated user's role, or attributes, you can Return 401 Unauthorized - If the user is not authenticated Return 403 Forbidden - If user doesn'...


11

The end-IP is not published. The process actually works in a way the client (a user hitting the balancer) believes they are communicating with the balancer, while talking to an actual node. In a very simple explanation, most transactions work like this: A user makes request to the load balancer. The balancer decides which node is the most suitable (based ...


9

However, what about non-logged in (unauthenticated) users? We don't know for sure who they or where the request is coming from exactly, so can't easily rate-limit those requests or..? There are a couple approaches you can take. One is that you need a reasonably reliable origin identifier, for example IP address. You can rate limit by IP address, so that ...


7

When you use a software load balancer or caching proxy, that load balancer or caching proxy is a bottleneck – but it's a much wider bottleneck than before. Assume we have an application server that can only handle 50 requests per second, since it has to query the database and do all kinds of expensive stuff. How can we scale? If we add a second ...


6

To know if a request is from an authenticated user or from an anonymous user, you have to necessarily process the request (albeit quickly). This still means your application is vulnerable to a denial of service attack. You should be checking overall requests per second, and if a certain number is exceeded, you simply ignore the rest. That number should ...


5

You are assuming that the physical host has dedicated all of it's hardware to a particular virtual host. If the physical server has 8 processors and 32 GB of ram, and it dedicates 2 processors and 8 GB of ram to a VM, adding an additional VM which has another 2 processors and 8 GB of ram associated to it would increase the overall resources dedicated from ...


4

Lad balancer is work on layer 4 OSI. It decapsulate packet until port number and then directing packet with one of 3 mode. Load balancer can work on 3 mode : 1. Direct routing In this mode your realserver is use IP public. The balancer receive the packet and decapsulate until layer 4. If in load balance rule match, it will be redirect packet (without ...


4

As Ewan said, you'll need a load balancer. Some of them are known as "reverse proxies". Examples include Pound, HAProxy. If your webservices are hosted on Amazon Web Services, you can use the built-in Elastic Load Balancing, which also includes auto-scaling and many more features. Note that before you add more instances, you need to consider: what is the ...


4

Informed and Intelligent Decision ... Do you have data? If you had data, you would have the basis for rational decision making (as this would be very informative). Otherwise you have guess work which is the basis for irrational decision making (which some people are very effective at, if your asking then you're probably not one of those people). Are you ...


3

This is essentially how CDNs work. When a person in South Korea requests a given resource, the DNS server replies with an IP address of a reverse proxy located in Seoul. Another user from California will get a different IP address which may point to a datacenter in Oregon, and a user from Spain may get another IP which leads to a datacenter in Frankfurt. ...


2

The best way to scale servers in my experience is to do so at the networking level with a separate load balancer. This sits in front of your webservers and directs incomming requests to a particular webserver and can have quite complex rules for doing so. For example: You can add version headers to the request and have the load balencer direct requests to ...


2

That's one of those "it depends" questions. I am going to mostly discuss web server balancing here. Some do it by creating a hash of some pertinent information (client IP, target server IP and/or URL; map this to one of N backends). Some do it by taking any un-allocated incoming session and send it to an arbitrary backend, then that backend sets a cookie ...


2

In a system based on asynchronous messages (events), there is no concept of a synchronous “response”. However, some events might be related. Many message queues allow a message/event to have a correlation ID to determine how messages are related. For example: A client publishes an event with ID 123. A service receives the event 123, does some processing, ...


2

Are you losing anything ? Depends on whether you are dependant on the j2ee specs. For example JCA, If not then stay away. Stateless services are way more flexible in terms of Scalability. And more over its easy to refactor to microservices.


2

I would have thought this would have an answer by now as its a standard problem. I'm going to have to give a fairly generic answer im afriad as its not my specialty. Basically you have two load balancers, a master and a slave and a way to switch between them if one fails. Usually a shared ip address which is either active or not. Now you have both boxes ...


2

The database can only hold 1 write concurrently and does not support transactions. If this value is exceeded, the database responds immediately with an error code XXXXX. This is extremely bizarre for any modern database, but let's accept the premise. At a high-level, there are 2 approaches to concurrent data modifications: Pessimistic - This is lock-...


2

Reading the specs, the main point of your requirement is: An user should receive an immediate response that vote was accepted. To achieve that, you could separate out the vote-taking-part. Each of your two instances need to talk to a component responsible for that. Then the problem arises, this component becoming the bottleneck in your architecture. It ...


2

Even with the more modern load balancing techniques that you mention in place I think there might still be good reasons for using the DNS load balancing: probably less for balancing the load across the actual load balancing infrastructure (duh) but maybe for high availability reasons: that infrastructure may itself face outages or be in need of maintenance ...


1

Rather than reinvent the wheel I would explore software as well as potentially PaaS offerings in various cloud providers that solve all the sticky problems of HA and dealing with single points of failure. There are hardware load balancers (eg. F5 Big IP), software load balancers (eg. ngnix, HAProxy, Kubernetes, etc...) and cloud load balancers (AWS Elastic ...


1

Not really sure I understand what you are trying to achieve. But here goes. Problem summary You have a Messaging class with method transfer You want to spread the calls to transfer over multiple instances of the Messaging class You want the calling code to be unaware of the many instances first off. Don't use singletons. second. wrap Messaging in a new ...


1

Why not just broadcasting the message to all the nodes, and then let the nodes chose the messages they want to forward through WebSockets to clients? If you have a lot of messages (that much that the impact on the network becomes noticeable), using the user ID in the routing key may be the easy way to reduce the traffic between the MQS and the nodes. ...


1

In your example solution, jobs 1 and 2 manage to group similar values within the same source but jobs 3 and 4 don't. All jobs keep their total workload under 50. This example solution appears to be the result of a greedy algorithm that grabs the first possible match. In general, greedy algorithms have five components: A candidate set, from which a ...


1

There is no point introducing a cluster of app servers fronted by a load balancer, if all are pointed at a common "database" which is not designed to handle concurrency. I wouldn't call it a database at all because that implies it handles concurrency as one expects from a modern DBMS. Since the requirement is you cannot change that piece of the ...


1

A simple greedy approach should fulfill your requirements. I assume you have an ordered input queue with all actions to process, and a list of actions associated with corresponding users currently under (parallel) processing (lets call these "users under processing"). Whenever the processing of one action is done, it is removed, and you check the next ...


1

Scaling is hard. Scaling databases is even harder. If you have enough calls to often have simultaneous calls to database, even if you can avoid deadlocking it won't solve your problem, as latency will start to increase. You probably need another database server, and that comes with a ton of stuff to change to work with a cluster. I would take this chance ...


1

Here is an excerpt from a related question, specifically about scaling. Scaling across machines can be done in various ways. Likely what you will want is partitioning. The easiest way is by hashing on some request value to decide which server to send to. For instance, if your customer ID is an integer (or can be consistently reduced to one... e.g. with ...


Only top voted, non community-wiki answers of a minimum length are eligible