navigate_next

Senior Backend Developer Roadmap 2024: A Complete Guide

Dragos Nedelcu

Senior Developer and Founder at theSeniorDev

Are you a Backend Developer looking to get to the next level?

Yet, at the same time, you are overwhelmed by the amount of libraries and frameworks you don’t know constantly popping up in your newsfeed?

You see job postings demanding countless buzzwords, from programming languages like Rust or Go to frameworks and tools like Terraform or Kubernetes. To design patterns such as the SOLID principles and functional programming skills.

And let’s not forget about the Backend Technical Interview.

Where data structures and algorithms are the norm, you should spend months on LeetCode to learn things you won’t even use in your daily job.

At least Front-end developers have it a bit easier!

They also have to deal with dozens of libraries and frameworks, but at least their stuff is confined to the browser. We can’t say the same about the backend.

If you think frontend is a mess with it's hundreds of frameworks and libraries, wait for the backend.

In the backend you have different frameworks and different programming languages. Then, we have different architectures, from monolith to microservices and event-driven systems.

Finally, we have deployment and scalability, with a trillion web services, from serverless to traditional computer instances and three different Cloud providers to master (AWS, Azure, and GCP).

If you feel overwhelmed, I don’t blame you. I was in your shoes when, as a front-end developer, I wanted to learn backend and become full-stack.

Well, my dear Padawan, fear no more!

In this article, we will reveal the exact skills you need to master to become a Senior Backend Developer in 2024 and beyond.

You will see how you can level up following the clear path without spending months on LeetCode or reading hundreds of System Design books full of theory but little practical advice.

When you realize Backend Development is much more than the Algo problems, FAANG interviews have been pushing down your throat.

So you don’t get stuck chasing shiny frameworks or burn out coding on the weekends and make real progress instead!

Regardless of your current level as a backend developer, you will find step-by-step instructions on how to get to the Senior level. This roadmap also works if, like me a few years ago, you are a frontend developer wanting to move into the full-stack in the right way.

Time is of the essence, so let’s get started!

Introduction

Now, if you expect me to start this Backend Roadmap with an introduction to Node.js, my friend, you are in the wrong place!

I'm just joking. But the reality is a Backend Developer is not a Node.js Developer!

Sure, you can build backend services using Node.js. And, if you already know JavaScript, I understand that will be your first pick.

Don’t get me wrong— Node.js is great. But Backend Development is not Node.js development.

You can also build backend applications using Python, Ruby, Java, Go, Rust, C#, and many other languages.

Each of those programming languages brings its ecosystem, frameworks, and libraries, which makes it even more confusing than the frontend!

Given that backend development is so fragmented, it is more important than ever to master the Fundamentals first and then explore frameworks and libraries.

Side Note: for the Node.js fans, don’t you worry. I have a strong focus on JavaScript myself. We will come back to Node.js and its libraries later on. Remember that we will talk about TypeScript, as type safety is even more critical in the backend.

🚀 Want to find out your technical gaps as a JavaScript Developer? Take this FREE Technical Assessment to find out what you need to focus on to get to Senior and beyond. 🚀

1. Backend Fundamentals

As you already know, the fastest way to master anything, from basketball to software, is not to get distracted by fancy techniques and focus on its fundamentals first.

But what are “Backend Fundamentals” in the first place?

Given that backend development is mostly about manipulating data, storing it, and sending it back to a client. Today, in the internet age, all that happens over the network.

This means the first thing that we will start with is… Networking!

1.1 Networking

To be a Senior Backend Developer, you don’t need to be a networking expert, but you do want to understand the basics.

You should know how the IP protocol works, what the Domain Name System (DNS) is, what the TCP and TLS protocols are, and how they all work together.

HTTP(Hypertext Transfer Protocol) is the blood of the web. It's a foundational protocol.

You should understand the basics, like what a request and a response are and what HTTP verbs are. Also, pay special attention to the headers and the body of an HTTP request.

In my early years as a Junior Developer, I was so focused on frameworks that I completely ignored learning more about HTTP.

Learning about request statuses seemed quite boring compared to all those fancy logos and tutorials. Whatever happened over “the network” seemed like magic.

Ignoring “the Fundamentals” as a backend developer might cost you the project and your career.

Every time I would face a network error, it took me days to figure it out.

No matter how good I was at React or JavaScript, not knowing the fundamentals of HTTP made me look mediocre. It also reminded my tech lead that I don’t have a CS degree.

My advice?

Even if it seems boring, this stuff will make you stand out. So learn it!

Most developers don’t know the most basic HTTP response codes(200, 404, or 503). Pity for them. Let them struggle and impress everyone with your “boring knowledge.”

Now that you know the fundamentals of HTTP, we can proceed with more sophisticated things that build on top of it.

💡 Main Concepts: IP protocol, Domain Name System, TCP, TLS, HTTP.

1.2 Web Mechanisms

Now that you understand HTTP, it is time to dive into the Web Mechanisms that build on top of it.

These are Content Negotiation, basic Authentication (as a foundation of advanced Authentication later on), CORS(Cross-Origin Resource Sharing), and HTTP Caching.

Content Negotiation is how the server selects the right format for the content it sends to the client (contained in the Accept HTTP Headers).

Basic Auth is built into the HTTP protocol. However, it is not really secure unless used with HTTPS.

CORS or Cross-Origin Resource Sharing prevents unwanted domains from requesting resources unless specified.

Good knowledge of HTTP codes will make debugging much easier. A funny way to learn them is HTTP Cat. Take a look :)

Finally, HTTP caching involves using HTTP headers to cache resources (store a copy of them). As always, with caching, what matters is to manage your cache properly as the resource is updated.

With this fundamental knowledge, you should be able to grab an HTML file, ship it over the network to a web browser, and understand everything going on (by reading the HTTP headers using your web browser or a tool like Postman).

By the way, I advise you to do just that!

I still remember the first time I was able to ship a file to the frontend with a basic Node.js server. That “Aha!” moment motivated me to improve my backend skills and move into the full stack.

Now that you know web mechanisms, it is time to go beyond the Network tab and start writing some serious backend code.

💡Main Concepts: CORS, Content Negotiation, Web Authentication, HTTP Caching.

1.3 Programming Paradigms

Now, if you want to add logic to that backend service, you need to be able to model it correctly. Otherwise, it will become an unmanageable spaghetti code monster.

The only place you want to have spaghetti at is an Italian restaurant. Not in your codebase.

This is what programming paradigms help us with.

❗What is a Programming Paradigm?

It is a style of programming, a way to think and structure code. Each paradigm has its principles and concepts, as well as disadvantages and advantages. The main programming paradigms are Imperative, Declarative, Functional, Object-Oriented, and Event-Driven Programming.

In the backend OPP, Functional Programming and Reactive Programming are the most popular programming paradigms.

Don’t get too distracted by OPP v.s. FP discussions. Both paradigms are useful and there is no one size fits all.Type image caption here (optional)

Let’s start with the first one, Object-Oriented Programming.

1.3.1 Object-Oriented Programming (OOP)

The first and most foundational programming paradigm you will have to master as a backend developer is Object-Oriented Programming (OOP).

Yes, I said it. I know some will hate me for this.

But OOP still rules backend development. The idealists will say that a program like Lisp(functional programming) is much better than, for example, Java(OOP). The reality is OPP, even if not perfect, is still widely used.

I guess that is because it is more natural for the human brain to think in objects than functions. We see objects in real life, and oriented thinking doesn’t require much math.

When discussing OOP, some fundamental design principles and patterns come into play, such as the SOLID principles and Class Design Fundamentals (Inheritance, Access Modifiers, Abstract Classes).

Afterwards you can move on with more advanced Backend Design Principles (such as Dependency Injection and Inversion of Control).

Don’t worry if you are not proficient or familiar with Class Design, particularly as a self-taught developer. Master the basics and pick the rest as you go.]

Make sure you don’t miss the so called “4 Pillars Of OOP” (Abstraction, Inheritance, Encapsulation and Polymorphism). Here’s a funny image for you to remember them.

Object-Oriented Programming might be the first programming paradigm you learn as a self-taught developer. Yet, if you want to call yourself a Senior, add at least one more programming paradigm to your toolbox. Let’s move on to Functional Programming.

💡 Main Concepts: Object Oriented Programming (OOP), Class Design, Encapsulation, Inheritance, Polymorphism

1.3.2 Functional Programming (FP)

Functional Programming has a steeper learning curve than OOP. It was inspired by some heavy concepts in mathematics.

And it introduces a new way of thinking (thinking in a functional way) and new ways to understand state (mutability/immutability, pure functions, side effects).

One drawback functional programming had, and why it didn’t have so much traction in its early days, was its demand for CPU power.

When writing functional code, we want to use as few variables as possible. So we compute intermediate values every time the code runs.

This constant computing moves a lot of pressure from the memory onto the CPU (because it needs to store and calculate all those function executions).

The main advantage of functional programming is that it makes for more predictable software.

In functional programming, everything is deterministic. This means you can predict the state of your application by knowing the inputs its functions will receive.

Functional programming might lead to more predictable applications, but its learning curve can be quite steep. Most people are not used to think “functionally”. Be patient and expect not to get it at the first time.

This is also why it became so popular even in the front end, which was traditionally more object-oriented (React being a pioneer here with React Hooks).

As a Senior Backend Engineer, you will be expected to know at least the basic principles behind functional programming and how to apply them to your codebase (pure functions, immutability, etc.).

Recursion is a core concept behind functional programming.

This is when a function calls itself in its definition. Counterintuitive I know, because humans are not used to thinking recursively.

As a Senior Backend Engineer you are expected to have a solid understanding of recursion and how it applies to functional programming.

Recursion will come in hand when optimizing the brute force approach in many data structures and algorithms problems (it replaces traditional loops). So get a good grasp of it.

“To iterate is human, to recurse divine. - L. Peter Deutsch”

I advise you to be patient when writing functional code. You will be challenged because it implies a new way of thinking, but don’t worry. Once you learn how to think functionally, everything will click!

🌟 Senior Dev Tip: Don’t get confused by all the fancy functional programming terms when you first start(like monads and functors). You don’t need a PhD in mathematics to write functional code. Just wrap your head around recursion, and you will be able to get going. See below.

💡 Main Concepts: Functional Programming, Immutability, Side Effects, Pure Functions.

1.3.3 Reactive Programming

This is the last programming paradigm you should consider as a backend developer. It focuses on asynchronous programming and data streams and uses more advanced programming concepts.

It proposes a more efficient mechanism than traditional request-response models, making it the best fit for real-world data. Reactive programming is the basis of Event-Driven Architecture, which we will discuss later.

For now, I will only limit myself to mentioning it, as it is way beyond the scope of this article.

1.4 Storage Solutions

Most Backend Services you build will need to store data. The most popular ways of persisting data are SQL and NoSQL databases.

Same as with programming paradigms, don’t get lost in endless debates over which database to use. Just pick the best for the use case. SQL for structured data, NoSQL for high volume of transactions.

Any Senior Backend Developer is expected to be familiar with both, so let’s explore them in the coming sections.

1.4.1 SQL Databases (Structured Data)

While the backend language you will be working with might change, any job you might be doing as a backend developer will require some knowledge of SQL.

SQL-based databases are great at storing structured data.

This is why it is the leading technology for data storage in many companies. Most business data is structured and can be easily modeled into SQL.

Think about SQL as Excel but for databases.

They have a strict shape of the data they store, also called a schema. To add new records to the database, you need to satisfy this schema. This is very different from NoSQL databases.

Don’t get fooled, even with AI being able to write quality SQL, as a Senior Backend Developer, you should still learn it.

Regarding how much SQL you should know, you should have at least basic knowledge of performing Select Queries, Basic Table Definition, Column types, and Inner/Right/Left Joins.

You should also know what makes a transaction ACID and why we need such transactions. Last but not least, make sure you understand what an ORM (Object Relational Mapper) is, how it works and why it is used.

As a hint, we use ORMs to model and query our database without writing too much SQL code. Using ORMs you write OOP code, but under the hood they handle all the complexity and generate SQL queries. Think about it like this, if SQL and OOP would have a baby, it would be an ORM.

For Senior Backend Interviews, common interview questions include explaining the differences between the Active Record Pattern and the Repository Pattern. Bonus points if you can give examples of projects where you used each of them and what was your decision factor.

Luckily, SQL is relatively easy to learn (but not easy to master). There are many great SQL tutorials, such as SQL Fundamentals and PostgreSQL for Everybody.

🌟 Senior Dev Tip: During backend technical interviews, you might be asked to write a “join” operation on the right, left, or both(outer/inner). Make sure you review “join” operations before the interview.

💡 Main Concepts: SQL Databases, ACID transactions, Right & Left Joins.

1.4.1 NoSQL Databases (Unstructured Data)

The case for NoSQL comes when you have to handle large amounts of unstructured or semi-structured data.

Like when handling analytics data with hundreds of data points and transactions or real-time web applications. NoSQL databases are great at handling fast transactions and vast amounts of data, like Big Data.

There are many kinds of NoSQL databases, but most backend interviews will be focused around Document databases like MongoDB. Far away on a second place are Graph databases like Neo4j, so make sure you understand how they work and what their use cases are.

How much should you know about Document databases like MongoDb?

At a high level you will need to know how BASE transactions are different from ACID. How Mongo can scale horizontally compared to SQL based databases (which naturally scale vertically).

Screening call interviews might include low level implementation questions like what does the “$in” operator do in Mongo. I know, being asked technical questions over the phone by a recruiter that doesn’t really understand neither the question nor the answer is annoying, but is the state of the developer job market in 2024. Don’t hate the player, hate the game.

If you work at a startup, you might be first exposed to a MongoDB database because startups are addicted to affordable Firebase plans. That’s not an excuse for you not to improve your traditional SQL skills. Don't wait until you fail your next technical interview to do that!

🌟 Senior Dev Tip: A basic understanding of how computers work (RAM Memory, Disc) will help you better understand how to architect and optimize your backend services.

💡 Main Concepts: SQL Databases, ACID transactions, Right & Left Joins, BASE transactions, Active Record Pattern, Repository Pattern

1.5 Data Structures And Algorithms

To become a Senior Backend Developer, you must pass a technical interview. These days, backend developers are interviewed mainly on Data Structures & Algorithms, and System Design.

No matter how good you are at crunching Leetcode problems, it won’t guarantee you the job. Unless you have some other technical skills like the ones mentioned in this Roadmap.

Given the depth of both topics, we won’t cover them in this article. Each deserves an article in its own right.

Note: We will discuss many System Design concepts in the System Architecture section later, but they won’t be tailored to the interview process.

2. API Design AND Development

A large percentage of your work as a Senior Backend Developer will involve interacting with some kind of API. Sometimes, you will have to integrate these into your own services, and other times, you will have to build, test, and document them for other developers.

Solid API knowledge is one of the cornerstones of your expertise, even more important than Data Structure and Algorithms. You will probably work with APIs more than anything else in your stack.

Let’s dive deep into them.

First, let’s clarify that API does not mean REST API. There are vast differences. Don’t worry; it took me three years of writing code to understand that (fundamentals, remember?).

An API or (Application Programming Interface) is an interface for applications or modules to interact with each other. You will find APIs in web applications, operating systems, database systems, computer hardware, or software libraries.

APIs are functions you can use to interact with an application/module. Think of them like the steering wheel in your car. It is a simple interface, but it is the power behind the complexity of your engine.

On the other hand, a REST API (Representational State Transfer Application Programming Interface) is a set of protocols and standards for structuring APIs that communicate over the Internet or HTTP.

Hope your APIs are looking better than that, but you’ve got the point.

Senior Backend Developers build, test, document, and extend hundreds of APIs during their careers, so let’s dive deep into them. API Developer would be a more accurate job title for many.

2.1 REST APIs

As mentioned, REST APIs are an architectural pattern used to structure APIs that communicate over the internet. They are a structured way to build your APIs, making them performant, scalable, and secure.

Why structure?

Structure makes things easy to build, document, test, and understand, which is precisely the kind of backend services we want.

REST APIs are built on top of the HTTP protocol and use a standardized communication method between client and server.

You might be wondering what are those “standardized ways”?

REST API principles might seem restrictive, but that’s exactly the point, to stop you from making mistakes when designing your APIs.

They are called the REST API Design Principles, and we will explore them in the next section. Pay attention. They might come up in your next backend interview.

🌟 Senior Dev Tip: REST APIs are a boring, overlooked topic that fresh developers like me ignored back in the day. Again, they seem dull on the surface; they don’t have fancy names or tooling. Don't get fooled by that. We are moving towards an “API economy” where companies build value into their APIs. Getting good at building REST APIs is one of your best opportunities to stand out.

2.1.1 REST APIs Design Principles

Working with backend developers daily, I am surprised by how many of them cannot say if an API is Restful when presented with the codebase.

To keep it short, RESTful APIs adhere to the following design principles: they must be stateless, you have to use a predefined set of operations(GET, POST, PUT, DELETE) to interact with their resources, and their resources are identified via a URI (Uniform Resource Identifier).

What does stateless mean?

A REST API being “stateless” means that each request from client to server must contain all the information needed to understand and complete the request. The server will not store any state about the client session on the server side.

How much should a Senior Backend Developer know about REST APIs?

As much as humanly possible!

For starters, aim to understand how to design REST endpoints while avoiding breaking the REST principles. We will discuss documentation and versioning later on.

How to test REST APIs

For now, let’s talk about how to test a REST API.

API testing will appear in almost all backend interviews. That is if the interviewer is any good :)

When testing a REST API, expect the usual tests, such as Unit Testing, Integration Testing, and End-To-End Testing.

Even if your team or company doesn't invest in testing, you should. There is a reason why every backend interview contains testing questions. It is crucial to producing quality software.

All of them are quite straightforward except maybe integration testing, which depends more on the kind of database you are using (as you will be testing the integration with the database).

The most effective way to test REST APIs is integration testing. Meaning we test our API from the “outside” by sending requests to it using a test framework (ex. Jest & Supertest).

To make this work you will need to provide a fake database (also called a “test double”). Make sure you seed this database with similar data to your production system, you will also have to reproduce the schema if it is an SQL database (using database migrations).

To test REST APIs performance under heavy traffic, we can use load testing.

This can help us understand which parts of the API could become performance bottlenecks. We can then think of a caching strategy or load balancing to mitigate those bottlenecks. As a hint, a common bottleneck can be the database, scaling your servers won't’ help you in that scenario.

Now, let’s move on to another core topic regarding REST APIs: documentation.

💡 Main Concepts: REST Principles, Stateless, REST Endpoints, Load Testing, Integration Testing, Test Doubles.

2.1.2 REST APIs Documentation

Documentation is so important because, in most cases, you will be building REST APIs for someone other than yourself (another backend dev or a frontend one).

If you want them to use your little creation, you must first help them understand how it works.

Properly documenting your APIs can be tedious, so backend developers ignore it. They hope the front-end developers will magically figure out how to integrate their APIs.

If you ignore documentation, prepare for other developers to ping you on Slack every five minutes, asking for trivial details.

Life’s too short for Slack messages.

Better ensure you document your APIs properly and avoid all that unnecessary hassle.

Lack of API Documentation is not only disturbing, but it will lead to extra communication with the developers using it. You’ve got better things to do. So document your APIs :)

Good API documentation will also allow for easier integration and fewer errors during implementation. You will also come across as a more professional backend developer, so there is no reason for you not to document your APIs!

First, there are many things you always want to include in your API documentation.

For starters, focus on endpoint(REST resources) descriptions, Response and Request examples, Rate Limits and Authentication. If you have more time, add a quick tutorial on how to integrate your API.

API Documentation Hint: Regarding API endpoints, you will want to document the following for each endpoint: the URL (including path and query parameters), the specific HTTP method (GET, POST, PUT, DELETE, etc.), required and optional request headers, response body format, possible status codes, and examples of successful and error responses.

Seems like a lot?

That’s because it is! Remember, we are talking Senior Developer here!

Don’t worry. You will memorize most of these concepts as you work with different APIs. Now that I have scared you, I want you to know that, luckily, you don’t have to worry too much about API documentation.

Tools like Swagger (based on Open API Standards) will allow you to generate most of this stuff out of the box! You just need to know how to set them up and check that everything makes sense!

You can also use Postman to generate basic documentation, but I'll let you figure that one out yourself!

Time to move on with API versioning.

🌟 Senior Dev Tip: Tools like Swagger will prove extremely useful when conducting technical interviews. A well-documented tech challenge will help you stand out from the mass of other backend developers who only focus on the code.

💡 Main Concepts: Open API Standards, Swagger

2.1.3 REST APIs Versioning

As the name suggests, API versioning involves keeping different versions of the API as you release updates maintaining backward compatibility. So old API consumers can use the API without changes after the update.

How do you version a REST API?

To version a REST API you can add the version number in the URI path, as a query parameter (this one is harder to cache, but it keeps your URL path clean) or using a Custom Header.

The best and most used is URL based versioning. Here is how the URL of you API would look once you implement versioning:

- by URL: myapi.com/v2.0/resources

- by Query Params: myapi.com/resources?v=2.0

- using a Custom Header: myapi.com/resources and Accept-version: v1

Okay, enough of REST APIs for now.

Time to move on with a shiny object that surprised the software community when it was released. Of course, they didn’t take it seriously until it really got mainstream.

2.2 GraphQL

Back in 2017, Bogdan and I would hang around Berlin at GraphQL meetups, where speakers would ask developers if they were using GraphQL in production.

Around 2 to 3 hands would raise.

A few years later, GraphQL became a mainstream choice for data layer technology. And a must for any backend developer aspiring to become a Senior Developer.

Before we jump into why you need to know GraphQL, let’s start with a bit of history.

With the rise of mobile devices, developers realized that smaller screens mean less data required to show to the user or differently structured data. REST APIs lacked the flexibility needed to accommodate those needs.

Remember, REST APIs are built around resources, not queries. But front-end developers wanted more flexibility in querying data from the backend. They needed something that was data-centric rather than resource-centric.

The answer to this question came from Facebook’s engineers, and GraphQL was born.

Which uses the power of graph-like schemas to give you, as a developer, the flexibility to query only the data you want. It is like, hey, here is only the data you need.

The main idea behind GraphQL is that you query data against a centralized Schema, navigating a graph-like structure. You can query fields by cherry-picking the data you like.

You can imagine Front-End Developers were very excited when GraphQL came out, pushing for its adoption. For back-end developers, GraphQL meant better communication with the backend and more transparency (because of the Strongly Typed Schema).

At the same time, GraphQL has led to more complexity.

The idea that you can now only query the data you need is due to GraphQL’s resolvers, which do the hard work for you.

Depending on how your app is structured, even if the client only requested specific fields, you might still have to resolve the whole object in the backend. This can get complex quickly and even result in an overall drop in application performance (resolvers are also called recursively, which makes them not so easy to understand).

On top of that, having a unique query adapted to “only the stuff you need” makes caching more complex, requiring new libraries and tools.

Overall, GraphQL can be a great tool in the backend, yet before jumping on the hype train, make sure you understand its pros and cons.

When working for a company that runs GraphQL-based APIs in production, you will be able to explore more advanced topics, such as scalability, testing, and caching. For now, we will move on to Web Security.

💡 Main Concepts: GraphQL, Queries, Resolvers, Schema, n+1 Problem, Graphs.

3. Web Security Practices

You don’t need to be a Cybersecurity specialist to become a Senior Backend Developer, but you do need to understand your application's most common vulnerabilities, how to prevent them, and how to deal with them if they happen.

The good news is that most web security vulnerabilities are relatively easy to understand if you have full-stack knowledge.

Let’s start with exploring the fundamentals of web security.

3.1 Web Security Fundamentals

When discussing website security, we will focus on two main types of vulnerabilities: SQL Injection, CSRF and MITM (man in the middle attack).

The good news is that you don’t need to know these security vulnerabilities by heart. You only need to know they exist and recognize the mechanism behind them.

Understand, don’t memorize.

To keep it short, SQL injection involves injecting malicious SQL into the input field to expose the database.

CSRF is when an attacker tricks the user into making an action they are not aware of by clicking on a prefabricated link. The user must be already logged in the application that is being attacked (like your fav banking app). Luckily nowadays, there is not much you can do with a simple request (most of them implement MFA).

MITM attacks are done by intercepting the traffic between the client and the server, extracting credentials or sensitive information and performing actions on behalf of the client. A simple solution to deal with this is to encrypt the traffic between client and server - which is why most websites today use HTTPs.

Regarding HTTPs, you just need to know that it encrypts both the body and the headers of the request, which can only be decrypted if you have access to the HTTPs certificates. This is beyond the scope of this article, but it might come up in the Senior Backend Interview.

As the title indicates, these are the fundamental concepts behind web security. Expect them in the backend interviews and your daily work as a backend developer.

🌟 Senior Developer Tip: Most developers have very weak knowledge of security. Security is often overlooked in development teams, and good learning resources are scarce. This makes security another topic that you can use to stand out in technical interviews.

💡 Main Concepts: SQL Injection, CSRF, HTTPS, HTTPS Certificates, MITM Attacks

3.2 Advanced Web Security

Okay, not that you know the basics is time to get deeper, much deeper into web security.

Are you still with me?

Senior Developers are known for their technical depth, not for shying away from challenges.

Let’s start with one of the most basic Security protection you need to know, DDoS.

3.2.1 DDoS Protection

If you don’t know what DDoS(Distributed Denial of Service) is or what a backend developer like you should worry about in the first place, imagine losing your beloved backend job because of a nasty teenager.

It happened in the 2000s.

“A 15-year-old hacker who went by the name “Mafiaboy” orchestrated multiple attacks that took down the websites of companies like Dell, E-Trade, eBay, and Yahoo!”

This brilliant and nasty kid hacked a series of university computer networks and used them to DDoS the hell out of Yahoo.

DDoS attacks are still happening even to this day.

GitHub was attacked in 2018, and AWS was attacked in February 2020. If big companies like this get attacked, you should also worry about this one. Or at least know the basics about how to prevent it.

A DDoS happens when a flood of requests inundates your service (API, website) to the point that your backend system becomes overwhelmed and can’t perform anymore.

To prevent a DDoS, we use Rate Limiting, which limits the number of requests your server will accept over a particular time from a single IP address.

There are other ways to protect against DDoS, but we will leave that out as it is not in the scope of this article.

3.2.2 Dependency Scan

Web Security is complex, but there is no need to reinvent the wheel. Most common attacks are documented and fixed in the libraries we use.

Even popular libraries like "lodash" have security vulnerabilities you should be aware of.

Before installing that new shiny npm package you found on Stack Overflow, make sure you scan it using security software like Snyc or Sonar Cube.

💡 Main Concepts: DDoS, Rate Limiting, Dependency Scanning

3.2 Authentication & Authorization

On to one of the most important topics, and one that is hard to grasp for Junior Backend Developers: Authentication and Authorization.

Unfortunately, this is also one of the most asked topics in backend interviews, so you must master it.

‍3.2.1 OAuth

The first time I had to implement OAuth was when working as a front-end developer, and to be honest, I didn’t pay too much attention to it. My focus was on my React components. In the end, I got away with it by bugging my Senior Developer. You might not have the same privilege.

Before we dive into OAuth… a bit of history.

Back in the 90is you could get away with Basic HTTP Auth and some PHP session management. That’s not the case anymore (see MITM attack).

The solution was the OAuth framework which outlined a secure way of authentication between server and client using JWT tokens and a new service, the Identity Tenant.

Diving deeper into how OAuth works is beyond the scope of this article and it deserves an article of its own.

How OAuth works is once a user logs in with their credentials, the Identity Tenant generates a token. This token is sent to the client, who stores it (either in HTTPs only cookies).

In the subsequent request, the user doesn’t have to send the credentials to the Identity Tenant (username and password) again. The client will now send you the JWT token back using the Authorization HTTP header.

You validate the token in the backend by calling the Identity Tenant Again and decoding it to obtain information about the user and their permissions.

Do make sure you understand the token lifecycle, how to manage access tokens, how to use refresh tokens, and what are the different grant flows. All those concepts will come up in backend interviews as you are expected to know them.

💡 Main Concepts: OAuth, Identity Tenant, Token Lifecycle, Access Tokens.

3.2.2. MFA

Now, suppose your product manager wants more security measures for your application.

They want to confirm the login on a mobile device. Congrats, you now have MFA or Multi-Factor Authentication. Your users find logging into your service annoying, but it is highly secure.

‍

Yes, MFA can be quite annoying, but it is for the better. It will keep your application secure.

Nowadays, MFA is delegated to third party service providers like Octa or OAuth0, so you won’t have to worry too much about it. Which will not move on to the next section.

With security covered, we are ready to tackle one of the most abstract topics you will deal with as a backend developer: System Architecture.

4. System Architecture

As our backend services continue to grow, we will need a way to structure them. Chaos makes for an unpredictable codebase.

That is the subject of System Architecture, which provides a wide range of design patterns and principles to help us organize our codebase.

4.1 Core Backend Architecture Patterns

As a rule of thumb, backend developers will have to deal with many different architecture patterns, a bit more than frontend developers. That is because things scale at a whole different level in the backend.

In the client (frontend, mobile apps), complexity usually comes from the UI (user interactions are complex) or the integration with the platform (web browser, mobile app).

In the backend, complexity comes mostly from scaling.

Before we explore fancy backend architectures and frameworks (like Redis and Kubernetes), let’s review the basic design patterns.

Pay attention, as many of those core patterns are foundational to the systems we will explore later in this article.

4.1.1 MVC (Model-View-Controller)

The Model-View-Controller Design Pattern has existed for decades. The Model manages the data and business logic, and as a backend developer, you will spend a lot of your time here.

The View displays the data (this can be the user interface, and the Controller handles user input and updates the Model, reflecting the changes in the view. The MVC design pattern enforces a strong separation of concerns.

Jokes aside, the MVC model makes it quite clear who is responsible for what.

The MVC model has been foundational to a few dozen frameworks, from Backbone.js in JavaScript to the .Net Ecosystem(ASP.NET MVC) to PHP (e.g., Laravel, Symphony, or CodeIgniter).

As a Senior Backend Developer, you should know the MVC pattern daily, including how to implement it in your framework of choice.

💡 Main Concepts: Layered Architecture, MVC, Separation of Concerns Principle

4.1.2 Microservices vs. Monolith

You will hear the word Microservices in almost every backend discussion. It means breaking bigger services into smaller ones.

With Monoliths being hard to scale and maintain, migrating to microservices seems obvious. But it is not until you find yourself digging through distributed logs for three days just to discover an error in service number 57 that you understand monoliths were not that bad.

As a refresher, a monolith is an application where everything is in the same place - all components are integrated. You are cooking your pie in one big pot.

The advantage of monoliths is that everything is easy to find. It all lives in the same application.

Quite a simplistic view, but it is a very visual way of seeing the Monolith v.s. Microservices debate.

There is also no need for internal authentication, as you can put everything behind the same authentication service. In monoliths, it is easier to find bugs. It is also usually easier to onboard new developers on the codebase and you only need one deployment pipeline.

The problem?

As you can imagine, monoliths scale poorly.

Imagine only one part of your system gets a lot of traffic. You want to scale it so it can handle the load. But, because everything is too tightly integrated, you must scale the whole application.

Same with building and deploying.

Monoliths' lack of flexibility has become even more annoying as teams and codebases grow. Soon, you have dozens of developers pushing changes from all different directions.

The solution?

Break everything into independent parts. This will allow us to develop, build, test, and scale different services independently. Worth mentioning here is Conway’s Law.

Microservices have started to take over the world.

Everyone started to break their Monoliths into smaller independent services, teams were easier to scale.

Microservices allowed for unprecedented scale and unprecedented complexity, with some of the biggest tech companies' architecture looking like this.

Now, years after the “Microservices Revolution,” some people are starting to miss the monolith.

With all their flaws, Monoliths made everything a lot easier.

Think about it: More services mean more complexity. Those services might have to authenticate with each other. It means individual deployment pipelines and cloud provisioning for each of them.

In software, complexity is bad for business.

This is why we are seeing this “Monolith Revival.”

Regardless of the setup you are working on, as a Senior Backend Developer, you should understand Monolith and Microservices Architectures well.

If you’ve done the homework, including solid Backend Fundamentals and a good understanding of REST APIs and Security, you will do fine.

At its core, Monolithic and Microservices Architectures are built mainly using the same pieces. What changes is the way we organize them.

🌟 Senior Dev Tip: Microservices will appear in almost every backend interview you do, particularly for Senior positions. Make sure you understand their pros and cons and prepare a few examples.

🌟 Senior Dev Tip: Between Microservices and Monolith, there is a spectrum of options. Like a Modular monolithic. Or a monolith surrounded by a few microservices. Let me know if you want me to go deeper into this, and I will take note for another article.

🌟 Senior Dev Tip: Frontend Developers faced the same issues with their monolithic React apps and copied backend devs by inventing Micro Frontends. Even if you are just working on the backend, it might still be worth checking them out.

4.2 Distributed Systems

Okay, the tiny startup you work for made it big. Their product is a success, and they want to scale at a planetary level.

Now, they want their backend services to support a few billion users (there will be around 5.35 billion internet users worldwide in 2024), so they decided to distribute their services.

Poor you. When you are about to get used to Microservices, it is time to scale to the Moon and back. Welcome to Distributed Architecture!

Well, the first thing you should know about Distributed Architecture is that it is similar to Microservices but at a bigger scale.

The main difference is that your Microservices are now duplicated using Cloud Services to hundreds of instances.

Besides the enormous amount of traffic, the amount of data distributed systems handle is also usually very large. Very, very large. PostgreSQL is not going to cut it anymore.

You will consider tools like Redis or Apache Kafka (balancing consistency, latency, and cost).

The CAP theorem tells you that you can’t have everything in life. Consistency, Availability, and Partition tolerance are mutually exclusive regarding databases.

You must start thinking about caching strategies, logging, horizontal scaling… etc. I would say the topic of distributed systems is even beyond Senior Backend Developers into the realm of Staff or Principal Engineers.

💡 Main Concepts: CAP theorem, Horizontal Scalability

4.3 Cloud Architecture

You’ve probably already heard the “but it works on my machine” statement. I was one of those “my machine” people myself. Guess what?

It doesn't matter that it works on your machine, it has to work on production as well!

And it has to run on development.

Screw it, it has to run everywhere! That’s precisely what Docker promised when it came out.

4.3.1 Docker & Containerisation

The fancy way to explain what Docker does is to maintain consistency across development environments. You package your application along with its dependencies into a single unit.

Then you can run that unit in any environment that runs Docker. This simplifies the deployment process.

Well, Docker not only promised, but it delivered.

Regardless of the flexibility containers give you, you should still be careful when operating them.

Docker is unparalleled in efficiency, isolation capabilities, scalability, tooling, and documentation. Life is easier when you throw your backend service into a Docker container!

This is why it became the de-facto solution for many software companies, particularly if they are doing microservices.

As a Senior Backend Developer, you should know at least how Containerisation and Docker work. You should know how to set it up. You should also learn a bit of Docker Compose.

💡 Main Concepts: Containers, Virtual Machines, Docker Images, Docker Compose

4.3.2 Orchestration (Kubernetes)

Well, not that we have containers… How can we scale them to the Moon and back? Billions of users are waiting!

Well, let’s just make more of them.

Sure, but we need someone to manage them, monitor their health and status, and ensure they work correctly.

Then Google shows up and says, “It is called Orchestration, and that’s what Kubernetes will do for you!” The software community follows.

If you think Docker is complicated, just wait for Kubernetes.

Kubernetes automates everything when scaling containerized applications.

It provides everything from deployment to scaling, management, networking, and you name it. It also provides high availability, load balancing, and great recovery features. It does this by grouping your containers into clusters and orchestrating them as they run.

With Kubernetes being so great, it's no wonder why every DevOps team out there preached about it. Yet, chasing shiny objects doesn’t always work.

Kubernetes might be a great tool, but it has many drawbacks.

First, it’s been designed for a huge scale that most small and medium-sized companies don't have. Scaling is complex and expensive.

Kubernetes can be pretty expensive to run and require a big deal of CPU and memory, depending on the size of your cluster. Add maintenance costs and security complexity and instead of saving costs with your fancy Kubernetes costs, you are generating them.

Finally, as any backend developer can tell you, Kubernetes is also not easy to learn.

It is easy to get lost between pods, services, deployments, and replicas. Imagine onboarding a Junior developer on all that!

Yes, Kubernetes has a steep learning curve, which makes it hard to grasp for many developers.

I believe a lot of companies running Kubernetes don't actually need it. And I am not the only one. But, they had some K8 fans in their team and a great deal of FOMO.

If you aspire to be a Senior Backend Engineer, you should at least have a basic understanding of Kubernetes, how it works, and its main patterns (Sidecar & Ambassador Pattern).

💡 Main Concepts: Sidecar Pattern, Pods, Replicas

5. Deployment & Operations (DevOps)

It would be great if backend developers wouldn’t have to worry about how to take our services to production once we finished coding. I mean, we already have tons of stuff on our plate.

Let the DevOps team take care of that. Is their piece of the pie!

In reality, even if DevOps will help you take your service to production, keeping it running smoothly will be shared. You must know how to get it to run yourself if the worst happens.

“You build it, you run it.” - Werner Vogels, Amazon CTO

This is why Senior Backend Developers are required to have a solid understanding of Deployment & Operations.

It also helps the company save money by hiring fewer expensive Platform Engineers. Which is why in startups, most deployment responsibility falls on the backend developers.

When talking about DevOps, let’s start with the core fundamentals: Continuous Deployment and Continuous Integration (CI/CD).

6.1 CI/CD

For starters, Continuous Integration means automating the integration of your code into the repository. Continuous Deployment means automating the deployment of that codebase to production environments.

Ideally, everything from commit to deployment should be automated. This allows faster deployment, especially if automated tests are integrated.

There are two parts to CI/CD: theory and tooling.

Some backend developers know the tooling but not the theory. They can fix pipelines but not build complete deployment cycles from scratch. Others know the theory but can’t implement it in their repos, which is as good as nothing.

Regarding the CI/CD concepts, understand terms such as pipelines, jobs, build server, artifacts, stages, and workflows.

There are dozens of tools available. You don’t need to know all of them. Even one that covers the whole deployment cycle would be enough. Jenkins, GitLab CI, CircleCI, Travis CI, and GitHub Actions are all strong choices.

The best way to learn this is to get one of your backend services, such as a simple REST API, and do the complete CI/CV setup, including automated testing.

💡 Main Concepts: Pipelines, Build server, Artifacts, Stages, Workflows.

5.2 Cloud Services

Given that the days of deploying applications on-premise (inside your company) are gone, as a backend developer, you will most likely deploy them to a Cloud Service.

The major providers here are AWS, Azure, and GCP.

All of them will try to sell you certifications in their technologies.

Getting a Cloud Certification is worth it if you have the time and resources. If not, I recommend you learn how to actually deploy services in one of those providers. No piece of paper beats knowing how to get things done.

Don’t worry about which Cloud Provided to choose.

They all kind of copy each other, so it will be easy to learn another one, for example, AWS. If you switch companies, the concepts are more or less the same.

5.2.1 AWS

A good start and also one of the most popular on the market is AWS (Amazon Web Services).

Focus on understanding its Core Cloud Services, such as Compute Instances (EC2), Container Management Services (e.g., ECS), Static Storage(Amazon S3), Databases (Amazon RDS, DynamoDB), and Networking Solutions (Security Groups, VPCs).

If you are interested, look at IaC (Infrastructure As Code) with AWS CloudFormation or Terraform.

One of the hardest things to deal with when working with AWS is IAM (Identity Access Management), make sure you get a good grasp of it.

In the last years AWS added hundreds of services which can make it pretty intimidating to start with. Focus on the services mentioned above and you will do just fine.

5.2.1 Serverless

The last step of evolution in Cloud Services came in the shape of Serverless technology.

AWS said, hey, this Cloud stuff you are doing is quite complex. Why don’t you give it to us? We do everything for you. And the best, you only have to pay when you use it.

Serverless means the Cloud provider manages infrastructure. The developer only has to provide the source code.

Serverless runs on demand, only when your services receive requests. Unlike traditional servers like EC2 instances which run continuously.

This saves costs when the traffic on the application is variable. You only pay for resources as you use them.

You don't need to be an expert in Serverless, but make sure you know what cold start and concurrency are. Bonus if you understand how API gateway, lambda and step functions work together.

🌟 Senior Dev Tip: Serverless is best for async programming, like creating thumbnails for an image you just uploaded to S3.

5.3 Monitoring & Observability

When running a backend application, you need to be able to react if something bad happens. For that, you have to be able to see what’s happening inside it and have some kind of system that warns you when things are not going well.

Here, HTTP logging and Push/Pull systems are worth mentioning. In terms of monitoring, APM metrics are all you need.

What is the difference between Logging and Monitoring?

Logging is about recording what happens and storing it for diagnostic purposes. Monitoring is the continuous tracking of what’s going on.

Think about it like this: Monitoring warns us there is an issue. To find the issue, we use the Logs.

One of the most used providers when it comes to logging and monitoring is Datadog. If you work with AWS, the default is Cloud Watch. If you want to go the open source way, then look into Prometheus and Grafana.

6. Emerging Technologies

As with everything in life, backend development is always changing, with new technologies popping up. If you want to stay relevant, you should check them out and even aim to learn some of them.

But don’t let them distract you.

I advise you to look into those technologies after your fundamentals are already solid.

The most important emerging technologies in the backend are Blockchain and Machine Learning & AI. Let’s dive deep into both of them.

6.1 Blockchain

You can think about Blockchain as a regular database, but distributed (it is called a ledger). The record of transactions is stored across multiple computers, which is fantastic because it avoids a single point of failure.

When Blockchain first came out, there was a lot of hype around it.

Everyone was talking about how the future of decentralized applications and traditional databases is on the verge of extinction.

I remember giving in to the FOMO and learning how to write smart contracts. Looking back, like many other developers, I overestimated blockchain's impact on backend technologies.

My time would have been better spent improving my backend fundamentals. Learn from me, and don’t make the same mistake as I did.

A core Blockchain feature is the ability to create Smart Contracts. These contracts automatically execute when conditions are met without intermediaries.

The most important platform here is Ethereum.

Blockchain as a backend technology has multiple use cases mainly due to its security and transparency. From financial services to supply chain and identity management, hundreds of startups use blockchain technology.

If you want to get a job at those companies, you should learn at least the basics of blockchain besides your backend knowledge.

💡 Main Concepts: Blockchain, Smart Contracts, Ethereum, Distributed Ledger

6.2 Machine Learning & AI

The elephant in the room is machine learning and AI, which, in 2024, threatens to make software developers obsolete, together with this whole article.

With the release of ChatGPT from OpenAI and tools like GitHub Copilot, which can write code, sometimes even better than experienced developers, it seems like coders are on the verge of extinction.

Not so fast.

Even if AI is pretty good at writing code, it is pretty bad at understanding why a particular piece of code is the way it is. And even so, coding is only a tiny fraction of a developer’s job.

Most developer time is spent dealing with ambiguous requirements, reading code, brainstorming, and designing new services (that and Memes).

So chill out. Yes, you will have a job in 10 years. Just implement what you learned in this Backend Roadmap.

Regardless, machine learning already plays a significant role in the backend. These models trained on historical data can make predictions without being explicitly programmed. They are great at forecasting, which is why businesses find them useful.

As a senior backend engineer, you should get a basic understanding of the most important Machine Learning models: linear regression, Decision Trees, and Neural Networks(which are super important for Deep Learning).

Finally, I would add LLMs (large language models) and their architecture, given that they are now part of everyday life.

In addition, machine learning systems need to be deployed into production environments for users to take advantage of them—just like any other kind of software!

And guess who’s going to do that?

Is the PhD Academic obsessed with improving the algorithm or the backend dev who knows everything about REST APIs and infrastructure?

By now, I hope you got my point.

Machine learning and its integration into backend services will generate a lot of work for ambitious backend developers. So check it out before Skynet goes online and it is too late!

Senior Dev Tip: With many companies trying to integrate LLMs into their software, learning to integrate with the leading providers in the space will help you stand out as a developer. For example, learning to work with the OpenAI API would be a great start.

💡 Main Concepts: Machine Learning, Predictive Models, Linear Regression, LLMs, Deep Learning

7. Methodologies, Soft Skills & Communication

Most Backend developers work in a team, usually a big team. They must communicate daily with dozens of other people, from product managers to frontend developers and colleagues.

This is even more true for Senior Backend Developers, who are required to lead the team, at least technically, and communicate with non-technical stakeholders.

Secondly, you should have a solid understanding of the different methodologies for building software iteratively, also called Agile.

This is a set of principles that aims towards early delivery, continuous improvement, and flexibility. Important management methods here are Scrum and Kanban. Be sure to check them out!

🌟 Senior Dev Tip: To improve your communication skills, I recommend you pick up a communication-heavy hobby, like attending drama or improv comedy classes or signing up for a public speaking club.

💡 Main Concepts: Agile, Scrum, Kanban, Soft Skills

We are finally coming to the end of this article, and wow, it’s been a long one! I hope by now you have a perfect understanding of what it takes to get to Senior Backend Developer.

Time to get to work!

Remember, it is not what you know but what you do with it. So go ahead and start right now. Pick up the topics in this roadmap and start mastering them. You will get to Senior in no time, and more importantly, you will have tons of fun in the process!

You can do it!

As for me, I will see you in the next one!

Take care,

Dragos

Final Note: given that this article was already getting too long, I left a few parts for part 2. Things like backend tooling, and Node.js specific topics, as well as advanced scalability and performance topics. Don’t worry I have them in my backlog!

arrow_back

Back to blog