Abstract
This page gives a brief idea about the implementation of a new system in a systematic and layered approach. Also how to design a system which composites Monolitic, and Microfoent end applications in a single platform. Over this design, we are trying to use multiple repositories, muti technology stacks, microservice architecture, external system connectivity and memory cache.
System Design Architecture
![Simple Architecture Design]()
In the above snippet, you can see multiple layers that will go through as stepping-stone methods.
- User Interface Layer
- Authentication Service
- API / Connectivity Layer
- Business Logic Layer
- External Connectivity Layer
- Cache Layer
- Repository Layer
- Analytics Layer
- Different Code Repository Usage
1. User Interface Layer
This User Interface layer is one which supposes to use by the end user, so we need to always be keen on the look and feel, performance and ease to use as per the current market. Typically this is the section, that gives an impression to our users about our portal or website.
In this layer, we used a name called Platform, what I meant here is, the platform is the abstract layer application which is the base, underneath we have multiple modules. For eg., Foundation is a platform and whatever we buildup is called an application under the platform. Another real-time example is, Telecommunication company is a platform which brings all these Broadband applications, Telephone Applications, FIOS applications, Value Ads applications and etcs., into a single platform.
Since we opting here as Micro FrontEnd Architecture, so no boundary for the technology stack. Once the application implementation work is done as a standalone, then the team need to get in touch with the platform team to plugin into the base. So it makes our life easy to swift any tech stack for any module. This keeps us innovative as well as gives good comparisons about the technology stack.
2. Authentication Layer
This plays a vital role nowadays, so please try to use an authentication mechanism as much as possible. This gives us only authenticated users who are probing our application. This methodology, basically based on the input feed, will generate an authenticated token, and based on the token we can traverse into our application. For eg., Based on the Credential, the system will generate a token to get into our application.
3. API/Connectivity Layer
The Application Programming Interface (API) is hypo nowadays, Basically, this is the gateway interface to external applications. Here we applied microservice API architecture, so each API does only the respective job accordingly. It won't take care of more than its responsibility and in this design, we created this as just a wrapper or router, it doesn't have any kind of implementation.
4. Business Logic Layer
In this layer, basically, this is the decision maker because all our business logic resides here, calling the external system, cache system, and repository layer. In this layer please try to use SOLID principles, Circuit Break Patterns and etc.,
5. External Connectivity Layer
While your system connects to external entities to communicate some data, please create a proxy layer. In this proxy layer, you can generate all proxies as a single point of contact for easy maintenance. All your external call should route from this layer.
Few real case scenarios while easy to maintain
- Calling the SMS service Maybe we need to change the third-party URL from HTTP to HTTPS
- We need to update WCF proxies because the external system exposed a couple of methods for our consumption.
- Whenever you generate a proxy please use svcutil, because you will get only the required proxy file instead of going for the disco reference option.
6. Cache Layer
Everyone expects a response very fast. So while developing applications we need to think strategically about which data are the same and which one suppose to be different. In this case, we can store lookup data in the cache because it will change once in a blue moon. another example is the same response for a day, so you can store those data in the cache instead of fetching them from the database.
Basically, the cache layer is one which avoids database hits to get the same sort of data which increases our response time. Please note that we need to make sure to clear the unused cache data, to avoid memory issues in the cache system.
7. Repository Layer
The Repository layer is one which is a gateway for our database. Only through this channel, we can get the data from our data. It doesn't have any business logic, basically, it does whatever you want in the database system. Again please try to use the SOLID principle and CQRS in this area, for instance, maybe today you suppose to use a Relational Database, but eventually, you plan to switch to a No-SQL database., so your design supposes to be easy to extend or switch to another system in future.
Optional: Create One as a Transaction Database and another as a Warehouse/ archive database, and then you can move your inactive data to the archive database.
8. Analytics Layer
Basically, this layer is optional, however, most of the systems use these layers in recent days. Instead of fetching data from multiple databases, try to use this approach so your transaction database won't affect for our any internal analytics work and this database is a single point of contact for your whole analytics work.
9. Different Code Repository Usage
Likewise, we use a multi-technology stack in the front end and microservice, and we used multiple code repositories to check in our code base. Again this gives much freedom to understand how different repository works. Moreover, this gives the flexibility to choose again different stack in future as a pragmatic approach.
I hope this article gives you a bit of an idea about how to approach layer architecture and why we are applying it while doing system design. In my next article let me give how to apply CI/CD pipeline.