The traditional SQL databases are used by developers as a fully safe storage. The ACID properties are intuitive for us and give us a sense of safety during application development. We know that if during a database transaction a network error occurred and we received an exception, the whole transaction would be rolled back as atomic part of process. To avoid network issues we can retry the operation later and it should solve the problem. It is true in most cases, but there is one when it is not so easy. Let me drill down this subject.
Sometimes system flexibility makes the solution complicated 😉 . Imagine a ‘simple’ situation that you have a system in which a client can define new attribute and assign multiple values to it. Later, the client can assign these values to the Customers. If you do not plan to develop new attributes’ set every time a client wants to make a change, you will need to prepare a ‘dynamic’ structure in the database.
Big companies have huge internal structures. The problem they have is that huge structures have to be mapped into a permission model. One company I worked for had over 300k groups in Active Directory. As worldwide organization they have multiple domains in AD forest. Of course, various groups have various memberships so the structure was really complicated.
Connecting front end and back end side is difficult. The main problem is the protocol itself. It is stateless. Connection is being re-created each time. HTTP/2 changes this behavior a little bit, but this is the transport layer only. Multiple requests/responses can be handled in a different order. It means there are many traps waiting for a developer.
SQL query engine is prepared to return correct results as soon as possible. But correctness means being correct from mathematical perspective. Problem that I will describe is obvious, but it is not what you sometimes expect from SQL engine.
Business requires fast software delivery. This sometimes leads to a situation in which developers are focused less on performance and more on business requirements. The problem is that badly designed architecture can unable to fix performance in the future. Many times I have explained that page with a total weight of about 2 MB is too large. I have explained that server side has a limited bandwidth. For 1Gb/s connection speed at server side you can handle about 50 concurrent users in the same time to show them full content in 1 second. I also tell my colleagues that we have to reduce number of requests. Each request not only consumes browser connection pool limit, but also server resources. When clients are located far from our server, pages can load very slowly. When I was on Galapagos I realized (again) how slow can a network connection be and how important wise web design is.
While making plans for my travels, I was wondering how to protect my administrator access to remotely accessible NAS. I noticed that this device offers two-factor authentication mechanism, which should increase security. This article will focus on this specific high level implementation.