Olamide | Backend Developer

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

Jesus Lover

[Olamide | Backend Developer @Dev_Olamide]

3/3

Building something outside your comfort zone is one of the ways of learning fast — and I'm documenting this journey.
Stay tuned.

[Olamide | Backend Developer @Dev_Olamide]

1/3

Building my first expense tracker API .

This is my first time building an expense tracker from scratch. Rather than keeping it simple, I decided to push myself with two features I haven't tackled before:

→ Web3 integration
→ Support for multiple bank accounts

[Olamide | Backend Developer @Dev_Olamide]

2/3

So far, I've completed:
✅ Middleware
✅ Models
✅ Authentication
✅ Authorization

I still have ahead of me; core expense/budget logic, analytics, and wiring up those two new features properly.

[Olamide | Backend Developer @Dev_Olamide]

@Akintola_steve Thank you sir for this

[Akintola Steve @Akintola_steve]

If I were to start Software Engineering all over again, knowing everything I know today, I would take a very different path.

I wouldn’t start by chasing frameworks.

I wouldn’t try to learn every programming language.

And I definitely wouldn’t spend years collecting certificates.

Here’s exactly what I’d do:

[Olamide | Backend Developer @Dev_Olamide]

@Jasper02_24 Omo😄😄

[Olamide | Backend Developer @Dev_Olamide]

Spent today learning Jest mocks & spies — jest.spyOn(transporter, "sendMail"), mockResolvedValue, mockRejectedValue.

Learned that spy.mock.calls[0][0] gives you the whole args object, not a specific field. Testing async code properly hits different.

#Testing #JesusSaves

[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