DEV Community: Mahmudur Rahman

🎉 Goodbye asyncHandler: Native Async Support in Express 5

Mahmudur Rahman — Wed, 14 May 2025 09:44:20 +0000

Express has long been a staple in the Node.js ecosystem, powering thousands of APIs and web applications. However, until recently, handling asynchronous route logic in Express has always felt a bit clunky — particularly when it comes to error handling in async functions.

But good news: Express 5 finally brings first-class support for async/await with native promise error handling! That means you can now write clean, modern async route handlers without wrappers like asyncHandler().
In this post, we’ll walk through:

🤯 The problem in Express 4
✅ The solution in Express 5
🛠️ Migration tips
🧪 Real-world example

🤯 The Problem in Express 4
In Express 4, writing async handlers directly like this:

app.get('/users', async (req, res) => {
  const users = await getUsersFromDb(); // what if this throws?
  res.json(users);
});

would result in an unhandled promise rejection if getUsersFromDb() throws or rejects.

Why? Because Express 4 does not understand that async functions return promises. It doesn’t await them or catch their rejections automatically.
Workaround: Using asyncHandler()
To deal with this, most devs used a helper like:

const asyncHandler = fn => (req, res, next) => {
  Promise.resolve(fn(req, res, next)).catch(next);
};

Then you’d wrap every route:

app.get('/users', asyncHandler(async (req, res) => {
  const users = await getUsersFromDb();
  res.json(users);
}));

Clunky, right?

✅ The Fix in Express 5
In Express 5, this boilerplate is no longer needed. You can now write:

app.get('/users', async (req, res) => {
  const users = await getUsersFromDb(); // if this throws, Express 5 will catch it
  res.json(users);
});

🎉 Express 5 automatically awaits promises and forwards errors to the error handler!

🧪 Real-World Example
Let’s say you have this:

app.get('/profile', async (req, res) => {
  const user = await findUserById(req.query.id);
  if (!user) throw new Error('User not found');
  res.json(user);
});

If anything throws (like a DB error), Express 5 will automatically send it to your error middleware:

app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ message: err.message });
});

No more asyncHandler. No more accidental unhandled rejections.
🛠️ Migration Tips
If you're upgrading from Express 4 to 5:

Remove asyncHandler() wrappers — just use async route functions directly.
Double-check your error middleware — Express 5 continues to use the (err, req, res, next) signature.
Update your dependencies — install the latest Express version:

npm install express@next

⚠️ At the time of writing, Express 5 is in beta (express@5.0.0-beta.x). Keep an eye on the official changelog for production readiness.

app.use(async (req, res, next) => {
  const isValid = await validateToken(req.headers.authorization);
  if (!isValid) throw new Error('Unauthorized');
  next();
});

Again, no try/catch needed — Express 5 has your back.
🧾 Summary
✅ Express 5 brings native async/await support
✅ No need for async wrappers
✅ Clean, modern error handling
✅ Works in both routes and middleware
✅ Big win for developer experience!

📚 References

Add Basic Error Handling to an Express 5 App
🙌 Conclusion
Express 5 may not seem flashy at first glance, but this feature alone dramatically simplifies writing clean, maintainable APIs with modern JavaScript. If you’ve been juggling asyncHandler utilities in Express 4, it's time to celebrate and simplify.

Happy coding!
✍️ Follow me on Dev.to or GitHub for more Node.js tips, architecture guides, and backend tutorials.

How Billions of Username Lookups Have Handled

Mahmudur Rahman — Thu, 10 Apr 2025 14:04:11 +0000

When you sign up for a new app and see a message like "This username is already taken," it feels like a tiny inconvenience. But behind the scenes, this simple check is a massive engineering challenge, especially when dealing with billions of users.

So how do companies like Google, Amazon, and Meta check username availability instantly without hammering their databases? Let’s dive into the smart strategies and data structures they use to make this process lightning-fast and scalable.

1. Redis Hashmaps: Speedy In-Memory Lookups

Redis hashmaps are a favorite for exact match lookups. In this structure, each username is stored as a field with a lightweight value like a user ID. A query checks whether the username exists in this in-memory store — delivering results in microseconds.

However, memory is finite, so Redis hashmaps are typically used to cache only frequently accessed or recent usernames.

2. Tries: Perfect for Prefix Matching

If you need autocomplete or want to suggest alternative usernames, tries (prefix trees) are a better choice. Tries store characters as paths, allowing searches to scale with the length of the string rather than the total dataset size. They also naturally support prefix queries.

To optimize memory, systems often use compressed tries like Radix Trees or limit tries to hot or recently entered usernames.

3. B+ Trees: Efficient Ordered Lookups

B+ trees are common in relational databases for indexing. They support fast, sorted lookups in O(log n) time and are ideal for queries that need range or alphabetical order, like finding the next available username.
Here's how:

Ordered Traversal: B+ trees store data in a sorted order and keep all values in the leaf nodes linked together. This allows the system to perform fast range queries and in-order traversal.
Next Best Option: If a desired username (e.g., alex) is taken, the system can quickly traverse to the next lexicographically available usernames (like alex1, alex_, alex123, etc.) without scanning the entire dataset.
Prefix Search: B+ trees can also support partial matches. For example, to suggest usernames starting with john, the system can navigate directly to the leaf node where entries like john1, john_doe, or johnny reside.
Efficient Suggestions: Since B+ trees maintain balance and logarithmic lookup times, even on massive datasets, they’re a great fit for generating sorted and relevant suggestions quickly.

Databases like MySQL, MongoDB, and Google Cloud Spanner use B+ trees (or similar structures) to power high-performance queries over massive datasets.

4. Bloom Filters: The First Line of Defense

Bloom filters are a probabilistic, memory-efficient way to check if a username might exist. If a Bloom filter says a name isn’t present, you can be sure it’s not. If it might be present, you do a deeper check in the database.

They use very little memory (e.g., 1.2 GB for 1 billion usernames with 1% false positives), making them perfect for large-scale systems. Systems like Cassandra use them to avoid unnecessary disk lookups.

The Power of Layering: System Architecture in Action

In practice, companies combine all these tools:

Load Balancing: Global (DNS-based like AWS Route 53) and local (like NGINX or AWS ELB) load balancers route requests efficiently.
Bloom Filters: Fast, in-memory filters weed out usernames that definitely don’t exist.
Caches (Redis/Memcached): Recently checked usernames are stored here for instant access.
Distributed Databases (Cassandra/DynamoDB): If all else fails, the system queries the authoritative source.

This tiered architecture minimizes latency, distributes load, and scales effortlessly across billions of users.

What seems like a simple check — "Is this username taken?" — is powered by a beautiful mix of computer science and engineering. From Bloom filters and tries to Redis caches and distributed databases, every component plays a role in delivering a seamless user experience.

Next time you pick a username, remember the complex machinery behind that instant response.

Inspired by a brilliant system design breakdown on YouTube. Want to dive deeper into similar topics? Let me know what you'd like to explore next!