Olamide | Backend Developer

Building projects on Javascript | Building APIs with Express | Consistency is key

Jesus Lover

[Olamide | Backend Developer @Dev_Olamide]

5/5

You can run that same container on:

- Your laptop
- Testing
- Cloud
- Production

The idea:

Build once. Run consistently anywhere Docker is supported.

That's one reason Docker became so useful in modern backend development.

[Olamide | Backend Developer @Dev_Olamide]

1/5

Docker eased developers' lives in a big way.

But what problem was it actually solving?

Let's use a real-world analogy.

🧵👇

#Docker #BackendDevelopment #DevOps #NodeJS

[Olamide | Backend Developer @Dev_Olamide]

4/5
Docker's solution?

Package your app and its dependencies into a container

Think of the container as a standardized kitchen containing what your application needs to run

Instead of recreating your environment, you can package it into a container and run it elsewhere

[Olamide | Backend Developer @Dev_Olamide]

@emmanuelao_ A lot oo bro

[Akintola Steve @Akintola_steve]

If you’re building serious backend systems, don’t stop at:

“Does it work?”

Ask:

What happens when it retries?

What happens when two requests arrive simultaneously?

What happens when the database is slow?

What happens when Redis goes down?

What happens when traffic spikes 10×?

What happens when the bill does too?

That is backend engineering.

[Akintola Steve @Akintola_steve]

Some backend concepts are easy to explain until you actually have to build them.

How do you prevent double payments?

How do you handle retries without duplicating work?

How do you stop a cache stampede?

How do you deal with race conditions?

How do you scale without quietly multiplying your cloud bill?

Let’s break down 20 backend concepts and how I’d actually implement them in production.

[Olamide | Backend Developer @Dev_Olamide]

@IsuhoFriday @X Let's connect

[Akintola Steve @Akintola_steve]

System Design Question for Software Engineers:

Imagine you’re building an Airbnb-like platform.

A guest searches for an apartment and sees that it’s available from September 10–15.

At exactly 11:59:58 PM, Guest A clicks “Reserve” and proceeds to payment.

However, payment processing takes 2 minutes.

While Guest A’s payment is still processing, Guest B also finds the same apartment and completes payment successfully at 12:00:30 AM.

Now here’s the problem:

Guest A initiated the reservation first, but Guest B’s payment was confirmed first.

If you allow both payments to complete, you have a double booking.

If you simply give the apartment to Guest B because their payment completed first, Guest A might have already been charged.

If you temporarily lock the apartment when Guest A starts payment, what happens if:

Guest A abandons the payment?
Their network disconnects?
The payment provider takes 10 minutes to respond?
Your server crashes after creating the lock?
The lock expires at the exact moment Guest A’s payment succeeds?

Question:

How would you design the booking system to guarantee that two guests can never successfully book the same property for overlapping dates, while still handling delayed payments, retries, duplicate requests, server failures, and payment webhooks arriving out of order?

How would you implement it? Give your takes then I’ll be plain in detail much later how best it should be implemented.

[Akintola Steve @Akintola_steve]

Let’s say you’re building a solution that requires a wallet system, where users can top up and maintain a balance.

Do you know that, without even realizing it, you could be building something that might eventually put you in trouble?

Let me explain.

You might build your application with completely innocent intentions for people to use, but bad actors could literally use your platform to launder funds.

Mr A opens an account on your platform.

Then suddenly deposits an outrageous amount of money, potentially laundered funds.

He gradually withdraws the entire amount over time.

And once he has successfully withdrawn all the funds, he requests an account deletion and moves on.

Now imagine hundreds or thousands of people doing something similar.

This is why, sometimes, building a feature is not just about writing the code and making sure it works.

There are things beyond the technical implementation that developers need to think about.

Now, to developers building applications with wallet systems:

How do you ensure your application doesn’t become a platform that can be exploited for things like this?

Or, if you’ve worked on something similar, what’s your take on it?

[Olamide | Backend Developer @Dev_Olamide]

Use soft delete temporarily, retain legally required records for the required period, then hard-delete/purge them when the retention period expires.

[Nundina @nundinaapp]

@Dev_Olamide Worth flagging the tension this creates with GDPR right to erasure though, soft delete for regulatory retention and a user's legal right to be forgotten can directly conflict, the actual answer is usually a retention schedule with a hard purge date, not indefinite soft delete.

[Olamide | Backend Developer @Dev_Olamide]

@nundinaapp Thank you

[Olamide | Backend Developer @Dev_Olamide]

Customer A deletes his account from a fintech app. A year later, a regulatory authority asks:
“We need the records of Customer A who used your platform”

If everything was permanently deleted, that could become a problem. This is where soft delete can be useful ⬇️⬇️

Short thread

[Olamide | Backend Developer @Dev_Olamide]

The important lesson:
“Delete” doesn't always mean physically erase everything immediately. In real-world systems, deletion should be designed around business, legal, and privacy requirements.

[Olamide | Backend Developer @Dev_Olamide]

Hard delete: Permanently removes the record
Soft delete: Marks the record as deleted without immediately removing it

Soft delete helps:
●Accidental deletion and recovery
●Audit/history preservation
●Regulatory requirements
●Maintain historical relationships and transactions

[Olamide | Backend Developer @Dev_Olamide]

JWTs make authentication scalable and convenient, but there's a trade-off between statelessness and immediate control over issued tokens.

[Olamide | Backend Developer @Dev_Olamide]

Imagine a user's refresh token is deleted, but their access token hasn't expired yet.

Shouldn't the user immediately lose access to protected routes?

With a purely stateless JWT setup, not necessarily. ⬇️⬇️

[Olamide | Backend Developer @Dev_Olamide]

Depending on the system, you can address this with strategies such as:
● Short-lived access tokens
● Refresh-token rotation
● Token blacklisting/revocation
● Token versioning