[WHY Series 2] E.001 — Server Re-design

I am working as a software engineer who likes to write code and to make service. An engineer is someone who solves a problem. I’d like to write this article to be an engineer who consistently discovers and solves problems. I want to share the problem and the solution I found with the WHY series article. I am looking forward to sharing it and receiving your feedback.

The service I’m making is related to various clients. We need to provide functionality to many clients in order to make one service, such as users, merchants, operators, and riders. In our service, the traffic of specific client can affect other client’s service because we have focused on just developing features so far.

Our service is growing rapidly, and we need a flexible environment to provide features for each client for bigger and more stable growth. So, ‘Distributed Server’ is mentioned continuously for that. I agree with the need for Distributed Server, but I didn’t response aggressively. Because I am sure that we can make a separate shit if we don’t define a clear reason and if we don’t consider an efficient and phased way.

So I’m trying to convince the members of backend chapter to get rid of the current shit to separate servers more well.

With the goal of ‘separating servers more well’, I looked into the problems that our servers currently have.

Why?

1. Ambiguous boundary between Business Layer and Data Layer

Basically, Business Layer should focus on business process and Data Layer should focus on common functions for data access. Currently, our server does not separate clearly between two layers.

• Business Layer includes some of the functions of Data Layer. As a result, the functions for accessing specific data have been implemented in the ‘Business Layer and Data Layer’ or ‘Multiple Components of Business Layer’. In addition, unnecessary references are generated between components of Business Layer to use that data access functions.
• The function of Data Layer is not abstracted enough. As a result, there is a continuous problem of directly accessing detailed information of other data components.

2. Unclear separation of concerns and responsibilities within Business Layer

The concerns and responsibilities of each component in Business Layer must be clearly separated. In our server, concerns and responsibilities are mixed. So, we have problems as below.

• There are unnecessary references between components. For example, the order component and the payment component cross referenced each other. The logic that should be processed in the payment component is processed directly in the order component, and the payment component uses that logic of the order component. Or, we are trying to solve within two components without separating new component although it is not responsibilities of the order component and the payment component.
• Responsibility of a particular component is not abstracted enough. For example, some of the functions that need to be handled in the user component are handled directly in another component. There is a logic to identify blocked users for any reason, but it’s not handled in the user component. It’s handled in another component directly.

How current servers are designed has a direct impact on the efficient and phased way of Distributed Server, so we are analyzing them in terms of our server design. The criteria are as follows.

• If this problem is not solved, it is difficult to define domains to separate.
• If this problem is not solved, there is a possibility that it will be separated into domains with duplicated features.

We set the goal of this work is to ‘re-design our server to separate servers more well with minimum resources’. In the next WHY series article, I will share some improvements of these problems.