Series 1: Building Enterprise Level Applications

Chibuezeadeyemi
4 min readJan 29, 2024

--

Hi, literally I will be talking about building enterprise level applications as a backend engineer. Some of the stuffs I will be talking about would contradict your insight especially if you are newbie to this industry — you just have to understand that, success in tech is dependent on our ability to learn, unlearn and relearn. You are in a good hand - trust me, I will give you a better way of building world class backend applications. Quickly let’s get started on this #series1

Understand your Architecture

In simple terms: backend architecture refers to the structure of your application. And as you may know: backend is the server side of every application, be it: web, mobile, IoT and more. The backend architecture determines how parts of the application communicate with each other to process incoming requests and create responses. When building a web application, select a backend architecture based on your specific requirements and factors, including cost (both ongoing and at scale), your application’s complexity, scaling goals, and your team’s expertise, and for the sake of this writing, I’m referring to enterprise level applications — that means building on projects like: Netflixs, Paypal, Instagram, and lot more.

Common Backend Architectures

  1. Monolithic Architecture: A monolithic architecture has a unified structure, with all the components of the application tightly integrated into a single code base. In a nutshell, it’s tightly coupled
  2. Serverless Architecture: A serverless architecture is a little bit tricky architecture. Just think of it as an architecture you need not manage any server. The cloud provider automatically manages the infrastructure, scaling, and resource allocation so that developers can focus on writing the code for their applications. A serverless architecture can either be structured as monolithis or microservices.
  3. Micro-Service Architecture: A microservice architecture is the direct opposite of monolithic architecture, meaning it’s loosely coupled. Several portions of the application are built separately — just something like distributed computing. These services may communicate through asynchronous messages, event-based channels, or directly by exposing an interface.
  4. Event Driven Architecture: Event driven architecture is a kind of micro-service architecture whose main means of communication is through Advanced Message Queuing Protocol (AMQP) — using Message Brokers like Kafka, RabbitMQ, or some other

Which Should I use ?

It’s better to understand that we are building a backend application for 100 million users at mind. As you know, a robust architecture is one of the solution to handle such a huge volume. I’m not talking about MVP, or starter projects. I’ll highlight some points you should flag out:

  • Never use a Monolithic Architecture: As simple and direct this may sound, it’s sometimes hard to do without. Because this architecture allows your entire API to be bundled within a single package, no call for thinking about maybe an entry point is down, no sending of request/messages — all you just have to do make the service class reusable. But here comes the problem, there’s much pressure on the application. Imagine running 5 different cron-jobs in this application, lot’s of resources will be consumed and you know what ? responses to requests will be slow, and the worst of it all the entire application eventually may go down.
  • Never stick to one architecture: As you may know, Monolith is out of it — I’ll recommend you use microservices architecture. This is certainly difficult that’s why you need a team, even sub-departments under engineering to handle several aspect of the application is a good idea. From the case above, cron-jobs could be a different application server on it’s own, transaction server as well as authentication server — this idea distribute the work-load across several servers. As I have recommended a microservice architecure, I know you’ve start to vision how communication between these processes is possible — this is a term called Inter-Process Commuincation (IPC), I’ll go into details in #series5, Just know that you can use REST, Message Broker, Socket IO, etc. Microservice architecture is tricky but there’re ways out — some of the ways are things like service discovery, circuit breaker, message broker and so on. Just chill, #series5 I’ll go in-depth.

Conclusion:

Today, we’d discuss about popular architecture to use — as you have know enterprise level application has it’s base as micro-service. The complexities and security have to be managed effectively. Ways around these are upcoming in subsequent series, feel free to subscribe to the news letter to get update. For now, it’s a goodbye — do me a favor by dropping your opinion in the comment section.

Gracias

--

--