DEV Community: Muhammad Uzair

Aurora v1 to v2 Migrating via Snapshot and Restore: A Step-by-Step Guide

Muhammad Uzair — Fri, 07 Mar 2025 21:52:04 +0000

In this blog, we'll cover the Plan B of our migration strategy.
To learn more about different strategies(differences, risk, steps, and comparison) including this one please read previous blog Migrate Aurora v1: Strategies Explained

Migrating using the snapshot-and-restore method involves taking a backup of your existing Aurora Serverless v1 cluster and restoring it to a new provisioned cluster that you’ll then convert to Aurora Serverless v2. This approach minimizes risk by allowing you to work on a cloned environment and provides an easier rollback path.

Database Migration Process

(Start Migration)  
      ↓  
(Verify Engine Version) → (Schedule Maintenance) → (Notify Stakeholders) → (Take Final Snapshot)  
      ↓  
(Test) → (Restore Snapshot) → (Upgrade Engine Version) → (Convert Writer Instance)  
      ↓  
(Add Optional Reader Instances) → (Trigger Failover)  
      ↓  
(Update Application Connection Settings) → (Validate Connectivity and Performance)  
      ↓  
           ┌───────────────────────────────┐  
           │      Migration Successful?    │  
           └───────────────────────────────┘  
                   ↙             ↘  
                Yes                No  
                 ↓                 ↓  
        (Finalize Migration)   (Initiate Rollback)  
                 ↓                 ↓  
        (Update Documentation)    (Restore from Snapshot)  
                                    ↓  
                               (Revert Application Settings)  
                                    ↓  
                               (Validate Rollback)  
                                    ↓  
                               (Notify Stakeholders Rollback)  
                                    ↓  
                                (End Rollback)

Milestone 1: Pre-Migration Preparation

Step 1: Verify Engine Version & Compatibility

Log into the AWS Management Console and navigate to the RDS Console.
Under Databases, select your Aurora Serverless v1 cluster.
Check the Configuration tab to confirm your engine version.
- If you’re not on a supported version (minimum PostgreSQL 13.6 for Serverless v2), plan a minor upgrade on your current cluster before proceeding.
Document: Record the engine version and cluster settings.

Step 2: Schedule Downtime and Notify Stakeholders

Plan a Maintenance Window:
- Choose a period with minimal traffic and inform all affected users.
Prepare a Rollback Plan: (provided at the bottom of this blog)
- Outline detailed steps to restore your original Aurora Serverless v1 cluster from a snapshot if needed.

Step 3: Backup Your Data – Create a Final Snapshot

In the RDS Console, select your Aurora Serverless v1 cluster.
Click Actions and choose Take snapshot.
Provide a name for the snapshot (e.g., aurora-v1-final-snapshot).
Click Take Snapshot and wait for the snapshot to complete (monitor the status until it shows as available).
Document: Note down the snapshot ID and creation timestamp.

Milestone 2: Restoring the Snapshot and Setting Up a Provisioned Cluster

Step 4: Restore the Snapshot to a New Provisioned Cluster

In the RDS Console, click on Snapshots from the left-hand menu.
Locate your snapshot (aurora-v1-final-snapshot), select it, and click Actions > Restore Snapshot.
In the restore dialog:
- Cluster Identifier: Provide a new unique name (e.g., aurora-provisioned-for-migration).
- DB Instance Class: Choose a provisioned instance type (e.g., db.r5.large) for the initial restore.
- VPC and Subnets: Ensure you select the appropriate VPC and subnet group to maintain similar connectivity.
Click Restore DB Cluster.
Monitor: Wait for the new provisioned cluster to become available.
Document: Record the details of the new cluster, including endpoint and instance class.

Step 5: Engine Version Upgrade (if Necessary)

Check: Confirm the restored cluster’s engine version.
Upgrade (if required):
- If your restored cluster is not at the minimum version required for Serverless v2 (e.g., below PostgreSQL 13.6), perform a minor upgrade:
  1. Select the restored cluster and click Modify.
  2. In the Database options section, choose the required minor version.
  3. Schedule the upgrade immediately if you’re in a maintenance window.
Document: Verify the engine version post-upgrade.

Milestone 3: Converting the Provisioned Cluster to Aurora Serverless v2

Step 6: Convert the Writer Instance to Aurora Serverless v2

In the RDS Console, select your provisioned cluster.
Click Modify on the writer instance.
Under DB instance class, choose the Serverless v2 option (often labeled as db.serverless).
Set Capacity Range:
- Minimum ACUs: e.g., 0.5 ACU (1 GiB RAM).
- Maximum ACUs: e.g., 8 ACUs (16 GiB RAM).
Scroll down and click Continue, then review your changes.
Choose to Apply immediately if your maintenance window allows.
Monitor: Ensure the modification completes successfully and the instance is now running as Serverless v2.
Document: Record the new Serverless v2 instance details.

Step 7: Add Optional Serverless v2 Reader Instances

For scaling read workloads, you can add additional Serverless v2 instances.
In the RDS Console, select your converted cluster and click Add reader.
Choose the Serverless v2 option and configure the desired ACU range.
Monitor: Confirm that new reader instances are active.
Document: Save the configuration details.

Step 8: Perform Failover to Promote the Serverless v2 Instance

In the RDS Console, select the cluster.
Click Actions and select Failover.
Confirm the failover, ensuring that one of the Serverless v2 instances becomes the primary (writer).
Monitor: Check that the cluster endpoint now points to the new primary.
Document: Update records with the new primary endpoint.

Milestone 4: Updating Application Configuration and Testing

Step 9: Application Connection Changes

Review Your Connection Method:
- Cluster Endpoint: If your application uses the cluster endpoint (a DNS name provided by Aurora), typically no changes are required.
- Instance Endpoints: If using individual instance endpoints, update the connection strings to point to the new Serverless v2 primary.
Test Connectivity:
- Run connectivity tests using a PostgreSQL client (e.g., psql) to ensure connections are successful.
Document: Note any changes made to connection settings and update internal documentation.

Step 10: Validate Performance and Monitor

Performance Testing:
- Run application-level tests to ensure performance meets expectations.
- Use Amazon CloudWatch and Performance Insights to monitor ACU utilization, CPU load, and replication lag.
Security and Networking:
- Verify that security groups, VPC settings, and subnet configurations are intact.
Document: Record baseline metrics and any observations during the testing phase.

Milestone 5: Rollback Procedure (If Issues Arise)

Step 11: Initiate Rollback to Aurora Serverless v1

If Critical Issues Arise:
- Immediately notify stakeholders and begin the rollback procedure.
Restore the Snapshot:
- Go to Snapshots in the RDS Console.
- Select aurora-v1-final-snapshot and click Restore Snapshot.
- Create a new Aurora Serverless v1 cluster using the snapshot.
Revert Application Changes:
- Update your application connection strings to point back to the original Aurora Serverless v1 endpoint.
Test Connectivity and Performance:
- Confirm that the restored cluster functions as expected.
Document: Log rollback actions and share a post-mortem with the team.

Common Issues & Gotchas

Serverless v1 cluster cannot be paused temporarily (for example, if you want to stop old cluster for while to verify if application crashes, you'll need to verify by other ways i.e cloudwatch logs, database internal activity (pgactivity)
After successful migration the cluster label will still be provisioned even though cluster is migrated. This is info bug and doesn't impact the working of db (i.e cluster will work as serverless v2)
You'll also need to migrate your database triggers (if any)

In next blog we'll explore Plan A (In-place migration) in depth.

Migrate Aurora v1: Strategies Explained

Muhammad Uzair — Fri, 07 Mar 2025 21:02:37 +0000

Aurora Serverless v1 is Saying Goodbye: Time to Migrate to v2

If you're using Aurora Serverless v1, you've likely heard the news: it's reaching its end of life. Let's be clear: you don't really have a choice. Migration to Aurora Serverless v2 is now a requirement to ensure continued support and to take advantage of the latest features and performance improvements.

AWS has announced the end-of-life date for Aurora Serverless v1: March 31st, 2025. We strongly recommend upgrading any Aurora Serverless v1 DB clusters to Aurora Serverless v2 before that date. The upgrade can involve a change in the major version number of the database engine. Thus, it's important to plan, test, and implement this switchover before the end-of-life date. Starting January 8th, 2025, customers will no longer be able to create new Aurora Serverless v1 clusters or instances with either the AWS Management Console or the CLI. For information about the migration process, see Upgrading from an Aurora Serverless v1 cluster to Aurora Serverless v2.

Aurora Serverless v2 scales more quickly and in a more granular way. Aurora Serverless v2 also has more compatibility with other Aurora features such as reader DB instances. You can learn about Aurora Serverless v2 in Using Aurora Serverless v2.

Why make the switch? Aurora Serverless v2 offers significant enhancements, including:

Faster scaling: Reacts more quickly to workload changes.
More granular capacity: Scales in smaller increments, leading to better cost optimization.
Broader feature support: Supports more Aurora features than v1.
Ongoing support and future enhancements: V1 will no longer get updates, V2 will.

So, how do you get from v1 to v2? There are two primary migration strategies, each with its own approach:

1. Intermediary Provisioned Approach (In-Place Conversion)

This strategy involves multiple in-place conversions. It's a more complex process where AWS handles the conversion of your Aurora Serverless v1 cluster.

Multiple in place conversions will be done.
This is a more complex process.
Higher Risk as changes are applied directly to production.

[Start Migration] --> [Convert to Provisioned Mode & Upgrade Engine] --> [Add Serverless v2 Instance & Trigger Failover] --> [Post-Migration Validation & End Migration]

2. Snapshot and Restore Approach

This method lets you minimize downtime by creating a new Aurora Serverless v2 cluster from a snapshot of your v1 cluster. It's like cloning your database onto a new, upgraded system. Here's how it works:

Create a snapshot of your Aurora Serverless v1 cluster.
Restore that snapshot to a new Aurora Serverless v2 cluster.
Update your application to point to the new v2 endpoint.
Cutover and then delete the old v1 cluster.
Cloning and restoring creates an isolated enviroment for testing.

[Start Migration & Take Final Snapshot] --> [Restore Snapshot to Serverless v2 Instance] --> [Update Application Connection Settings & Trigger Failover] --> [Validate Correctly and Monitor & End Migration]

Which strategy is right for you?

It depends on your tolerance for downtime, your comfort level with managing database snapshots, and your risk appetite.

Here's a quick summary to help you visualize the differences:

Migration Strategies Summary

Aspect	Intermediary Provisioned Approach	Snapshot and Restore Approach
Process Complexity	Multiple in-place conversions; more complex steps	Cloning and restoring; isolated environment for testing
Risk Exposure	Higher risk as changes are applied directly to production	Lower risk; original environment remains untouched
Downtime	Potentially shorter if executed well; risks of brief failover	May be longer due to restore time but safer overall
Testing	Limited testing on live system; staging is essential	Extensive testing possible in an isolated, restored environment
Application Changes	Minimal if using cluster endpoint; reconfiguration might be needed if using instance endpoints	Likely required if the restored cluster endpoints differ
Rollback Flexibility	More challenging; may require reverting conversion steps	Clear rollback by switching back to original snapshot

No matter which path you choose, planning is essential. Thoroughly test your migration in a non-production environment before making the switch in production.

In next blog, we'll explore each strategy in depth.

Aurora Serverless v2 vs. v1: A Concise Comparison of Key Differences

Muhammad Uzair — Wed, 19 Feb 2025 14:41:44 +0000

Comparison: Aurora Serverless v2 vs. Aurora Serverless v1

1. Database Engine & Compatibility

Feature	Aurora Serverless v2	Aurora Serverless v1
Supported DB Engines	Aurora MySQL, Aurora PostgreSQL	Aurora MySQL, Aurora PostgreSQL
Supported Versions	Supports newer versions (e.g., MySQL 8.0)	Supports older versions (e.g., MySQL 5.7)
Upgrading	Manual major version upgrades (e.g., PostgreSQL 13 → 14 → 15)	Automatic minor upgrades, but major upgrades must be done manually
Conversion from Provisioned Cluster	Add Aurora Serverless v2 DB instances to an existing cluster	Must restore a snapshot from a provisioned cluster
Conversion from Aurora Serverless v1	Upgrade process available	Not applicable

Example:

If you're using Aurora MySQL 5.7 in Serverless v1, you must migrate to a new cluster to use MySQL 8.0 in Serverless v2.

2. Scaling & Availability

Feature	Aurora Serverless v2	Aurora Serverless v1
Minimum Capacity (ACUs)	0.5 when running, 0 when paused	1 (MySQL) or 2 (PostgreSQL) when running, 0 when paused
Maximum Capacity (ACUs)	256 (MySQL & PostgreSQL)	256 (MySQL), 384 (PostgreSQL)
Scaling Granularity	Increments of 0.5 ACUs	Doubles or halves capacity (e.g., 2 → 4 → 8 ACUs)
Scaling During SQL Execution	Yes, no need to wait	No, must wait for transactions to complete
Multi-AZ Support	Yes, supports failover across Availability Zones	No, only runs in a single AZ
Failover Handling	Fast failover, like provisioned clusters	Best-effort failover, may take longer
Global Database Support	Yes, can replicate to other AWS regions	No, limited to a single AWS region
Buffer Cache Preservation on Scaling	Yes, dynamically resized	No, requires cache rewarming (may slow queries after scaling)

Example:

If your database needs to handle spikes in traffic, Serverless v2 can scale in 0.5 ACU increments dynamically, while v1 might double capacity abruptly, causing potential over-provisioning.

3. Networking & Connectivity

Feature	Aurora Serverless v2	Aurora Serverless v1
Port Flexibility	Any MySQL/PostgreSQL-compatible port	Fixed to default MySQL/PostgreSQL port
Public IP Allowed?	Yes	No
VPC Requirement	Yes	Yes, but requires extra interface and Gateway Load Balancer endpoints

Example:

If you need to connect from external applications, Serverless v2 allows a public IP, but v1 requires a VPN or AWS Direct Connect.

4. Feature Support

Feature	Aurora Serverless v2	Aurora Serverless v1
Cluster Topology	Supports mix of Serverless & Provisioned instances	Fixed Serverless-only cluster
Configurable Parameters	Nearly all parameters like provisioned clusters	Limited parameter customization
Encryption for Cluster Volume	Optional	Mandatory
Cross-Region Snapshots	Yes	Requires encryption with a custom AWS KMS key
IAM Role Association	Yes	No
AWS Secrets Manager Integration	Yes	No
Performance Insights	Yes	No
CloudWatch Logs	Selective logging	Uploads all logs automatically
RDS Proxy Support	Yes	No

Example:

If your application requires fine-tuned database parameters (e.g., adjusting innodb_buffer_pool_size for MySQL), Serverless v2 allows more control, whereas v1 limits what can be changed.

5. Use Cases & Adaptation

Use Case	Aurora Serverless v1 Approach	Aurora Serverless v2 Alternative
Lightly loaded cluster, cost efficiency	Minimum 1 ACU, single AZ	Minimum 0.5 ACUs, Multi-AZ for better availability
Dev/Test environments	Cluster pauses after timeout	Can pause manually or set 0 ACUs for auto-pause
Heavy workload	Scales by doubling capacity	Scales in 0.5-ACU increments for better control
Higher total capacity needs	Single writer instance	Multiple reader instances distribute load
Write-intensive workload	Limited writer capacity	Mix of provisioned writer & Serverless v2 readers

Example:

If you have a low-traffic dev/test database, Serverless v2 allows setting 0 ACUs (scaling to zero), whereas v1 only pauses after inactivity.

🎯 Summary: Why Choose Aurora Serverless v2?

More granular scaling → Adjust in 0.5 ACU increments instead of doubling capacity
Multi-AZ & global database support → Better availability & disaster recovery
Faster failover & cache preservation → Less downtime, better performance
More networking flexibility → Allows public IP access
More control over configurations → Supports parameter tuning, IAM roles, and performance insights

Aurora Serverless v2 is a better choice for production workloads that need scalability, high availability, and flexibility, while v1 is best for simpler, cost-sensitive use cases.

The Impact of AI on the Job Market in Different Countries

Muhammad Uzair — Wed, 19 Feb 2025 09:10:49 +0000

AI as Creative Destruction

It’s hard to argue that AI is just another (maybe a little more than that) example of creative destruction.

Basically, it’s the idea of how innovation leads to new ideas, products, and processes replacing older ones. As progress happens, jobs and industries tied to outdated technologies disappear, while new opportunities are created around the latest advancements.

For example:

Firearms replaced spears and bows.
Computers made typewriters obsolete.

And now, with AI, we’re seeing that same cycle play out, but on an even larger scale.

AI's Impact on the Job Market

I would split its impact in two different categories.

Impact on the Innovator Nations (basically innovative and creative countries and part of the world i.e USA, Europe etc)
Impact on Labor Hub Nations (basically consumer of tools created by Producing countries i.e Pakistan, India, Philippines etc)

Impact on the Innovator Nations

For countries that produce AI tools and technologies, there’s an undeniable need for more creativity and innovation. But there’s also a major dollar element here. These countries will demand more affordable labor, which likely means more job cuts in certain sectors, especially for lower-skilled positions. The pressure is on to innovate, but with that comes the challenge of balancing job displacement with the need for cost-effective solutions.

Impact on the Labor Hub Nations

On the flip side, countries like Pakistan, India, and others that primarily consume these tools to get work done don’t necessarily need to be more creative—they just provide cheaper labor. AI might not hit the job market in these regions as hard as it will in places like Europe or the U.S., because it actually makes the labor costs cheaper for the highly skilled and creative tasks.

Take an average developer in these regions, for example. They may have once worked on simpler tasks, but now with the help of AI, they can tackle more complex projects, making their skills even more valuable. AI, paired with affordable labor, could make these developers more in-demand than before, at least for a while.

Conclusion

I’m cautiously optimistic for Labor Hub Nations in the short term. While AI might lead to job cuts in developed nations, those that offer affordable labor could actually see a surge in job opportunities, at least for a while. AI can make their skills more valuable, enabling them to take on more complex tasks. However, the key question remains: how much will Innovator Nations continue to invest in technology and startups? The funding and budget decisions in these countries will shape the future, especially when it comes to how AI evolves and how it impacts global job markets.

Bike shedding Triviality in software development

Muhammad Uzair — Wed, 03 Jan 2024 08:04:50 +0000

Bike Shedding

The tendency to give disproportionate weight to trivial issues of a larger or more complex project. In other words, prioritizing something easy to grasp and/or is debatable.

Origin and Explanation

Parkinson used the example of a committee meeting discussing ways to finance three projects:

A £10 million nuclear power plant.
A £350 bike shed.
A £21 annual coffee budget.

The meeting starts with members discussing nuclear energy, but most are ill-informed and the project seems too complex to facilitate meaningful discussion. The committee then moves on to the bike shed and since many ride to work, there is more animated discussion regarding its financing. Lastly, the coffee budget is discussed. Everyone drinks coffee, so the colleagues spend the rest of the meeting talking about their favorite blends and the allocation of just £21.

At the conclusion of the meeting, nothing of significance has been achieved.

Parkinson summed up the results of the meeting by defining his law. Parkinson’s Law of Triviality states that the amount of time devoted to a task is inversely proportional to its importance. In other words, organizations devote large amounts of time to tasks that bear little significance to their bottom line.

Indeed, bikeshedding is a pervasive and well-entrenched problem in most businesses. A seemingly infinite amount of time is spent replying to emails and sitting in meetings that don’t seem to accomplish much. Ultimately, these somewhat menial tasks consume resources that could be better directed to major projects with a greater potential to move the company forward.

Common examples of bikeshedding in Software development

One of the common exmaple of bikeshedding is focusing too much on looks of end product instead of effect, behaviour of the project.
Stakeholders spend most of their time, mental effort and meetings trying to achieve visual needs of a project instead of focusing on vision, its impact, and answering how and why regarding requirements.

Process should probably start with good experience (without visual cues and colors) and that should leads to features development and later aesthetics should be handled based on user psychology and keeping end users characteristics intact (total users, age, country, gender) etc.

How does your team work to build features?

Muhammad Uzair — Tue, 05 Dec 2023 10:22:14 +0000

I am curious

about how different teams approach building new features when multiple developers or teams need to be involved in integrating or building a new feature within a product (excluding external service integration)

Interface Agreement approach

One commonly used approach is establishing an "interface agreement" between developers, such as the frontend and backend devs, before building a feature. For instance, before creating a new API or feature, developers come to an agreement on the request/response structure, defining the API interface. This allows them to work independently, without having to wait for the other developer to finish their part before integration.

Issue with this Approach
While this method works well on a smaller scale and is efficient for agreeing on interfaces for a few APIs, it becomes challenging when building an entire product or a feature that spans multiple use cases or APIs. The difficulty arises because it's tough to foresee or visualize how the entire set of interfaces will look upfront.

This challenge is more pronounced in traditional SQL databases, where you typically have a clear understanding of the data type, interface, or data to be retrieved and sent back.

The complexity increases, especially with NoSQL databases, where the stored data can be unstructured, and it might not conform to your expectations. For example, you might assume it should be an array, but, unexpectedly, it turns out to be a string for some reason (unless you are using an ORM or ODM).

The problem intensifies further when using dynamically typed languages like JavaScript, where issues may only become apparent when your frontend starts throwing errors.

3 Common Problems while learning to code

Muhammad Uzair — Sat, 08 Apr 2023 20:06:14 +0000

Here are some common problems that people face while learning to code, along with tips on how to avoid them:

Perfectionism:

Perfectionism can be a significant obstacle to progress when learning to code, or anything else for that matter. If you constantly strive for perfection, you may take longer to acquire new skills or become proficient. Learning is a gradual process, and it takes time to become fluent in any skill. So, instead of trying to achieve perfection from the outset, focus on learning bit by bit. Remember, Rome wasn't built in a day, and neither will your coding skills be!

Consistency and Discipline:

Maintaining a consistent learning schedule is essential to gaining and mastering a new skill. Often, we tend to put in more hours at the start when our energy is high, but we eventually start taking longer breaks, which can harm our overall performance. Therefore, it is crucial to remain consistent and disciplined when learning to code. Consider setting goals or taking on a challenge to keep yourself motivated and committed to the learning process.

Celebrate Every Success:

It's essential to take the time to celebrate every success, no matter how small, when learning to code. Enjoying every successful step or achievement towards your goal can help you stay motivated and inspired. For example, when you successfully execute a few lines of code for the first time, take a moment to appreciate your accomplishment. These little moments of happiness can go a long way in keeping you energized and enthusiastic about learning to code.

As programmers and tech enthusiasts, we know that learning to code can be a challenging but rewarding experience. By avoiding the common problems outlined above, you can optimize your learning and progress towards becoming a skilled coder. Remember to be patient, consistent, and celebrate every success along the way. Happy coding!

3 tips for beginners

Muhammad Uzair — Sat, 08 Apr 2023 19:55:24 +0000

Persistence

Becoming a proficient programmer takes a lot of time and effort. The path to success can be long, so strive to be consistent even if you only have half an hour a day. Consider joining the #100DaysOfCode challenge to help you stay on track.

Point: Joining the #100DaysOfCode challenge can help you develop consistency.

Practice

Understanding programming concepts is not enough to create projects. You need to put your knowledge into practice by starting a project or working on an idea that interests you.

Point: Start by working on a project or idea that interests you.

Use Google Instead of Memorizing

In traditional education, we are taught to memorize everything. However, in programming, it is better to learn concepts and use Google extensively to search for syntax, errors, or how to implement certain things. Don't bother memorizing definitions; focus on understanding and knowing how to use them. Learn to skim through things to take away important messages instead of dictionary meanings.

Point: Later, if you have an interview, you can go through a few articles to learn better ways of describing things or answering questions.

What lesson did you learn from your favourite tech show/series or movie?

Muhammad Uzair — Fri, 15 Apr 2022 00:48:57 +0000

What's your favourite tech, programming or business related TV show ?

What lesson did you learned from it?

Would you recommend it to others?

Your favourite part of the show?

Apps that don't scale (Fb, twitch, google) stories

Muhammad Uzair — Tue, 05 Apr 2022 00:59:11 +0000

Do you overthink making your yet-to-be-made app scalable? Great, you're not the only one, but should you?
Here are some scalability stories from the famous tech that you use every day.

Hope you'll find them insightful.

1) Facebook

As Facebook started as a little Stanford project and then started scaling the university campus-wise. Do you know how they used to do that?
Facebook used to have a separate server for each campus with each having its own code, MySql database, and memecache. Each time FB need to have another campus they would install a new server with its own server, code, and database.
Each user was restricted to its own campus, they would have a weird "harvard.facebook.com" type URL for each user.

Later when they decided to let different campus users talk to each other, it took them a year to come up with an efficient so-called single-global-table, where users can add each other globally.

2) Gmail

yeah I mean the defacto standard for emails, Gmail. Do you how it was initiated & scaled?
A guy name Paul Buchheit from google didn't like to use existing email clients because he wasn't satisfied with their UI. So he hacked together a little tool to just preview his emails in google groups UI & he liked it. Then he started adding little new features when he feel like it should have something else, like let's add a writing emails option, a delete button...

One day he showed his created little email client to his co-worker and he kinda likes it, but the problem was he wasn't able to use his email in it because Paul's email was hardcoded in it. Paul just realized he should make it flexible to allow for other emails to be used instead of his one.
People start to use it inside google, a day it went down & someone came to Paul and said, do you know Gmail has been down since morning. He said no, I was busy with work didn't know that :D

3) Twitch

Initially, video streaming cost was very high when twitch started, every little detail on their web page will fire a query to get data, e.g watch count, likes count, etc
They decided to cut the cost by loading all website data in cache except video and chat. Therefore video was played but none of the buttons was interactive except chat. All those data were being loaded from local storage.
Later they figure out a way to cache using different strategies.

4) Google

At some point google's algorithm to crawl pages become inefficient, it would take 3 weeks to crawl new pages.
Google stopped crawling new pages for 6 months & showed only the old crawled pages to users on search. The cool part was users didn't even notice that.

5) Friendster vs MySpace

Friendster used to have a feature to show you how far this connection is from you. But this little so-called important functionality was very expensive. It will fire a query for each user-friend multiple times to figure out by going through existing connections to figure out how this person is linked with the current user. This functionality would fire tons of queries & took a lot of time.
Myspace used the same feature but instead of finding a connection through multiple queries, they would fire a single query if the person is your friend otherwise they would show text, "this is your far connection" :D

Source: Y Combinator

Conclusion is, Don't stress too much about scaling before you even start, rather start small & scale with the time.
Do you know any similar stories? Please let us know in comment 👇

Solve problem of API responds with 401 error

Muhammad Uzair — Sun, 13 Dec 2020 12:36:28 +0000

Error:
Invalid API key. Please see http://openweathermap.org/faq#error401 for more info

API calls responds with 401 error:
You can get the error 401 in the following cases:

You did not specify your API key in API request.
Your API key is not activated yet. Within the next couple of hours, it will be activated and ready to use.
You are using wrong API key in API request. Please, check your right API key in personal account.
You have free subscription and try to get access to our paid services (for example, 16 days/daily forecast API, any historical weather data, Weather maps 2.0, etc). Please, check your tariff in your personal account.

here are some steps to find problem.

1) Check if API key is activated

some API services provide key information in dashboard whether its activated, expired etc. openWeatherMap don't.
to verify whether your key is working 'MAKE API CALL FROM BROWSER'
api.openweathermap.org/data/2.5/weather?q=peshawar&appid=API_key

replace API_key with your own key, if you get data successfully then your key is activated otherwise wait for few hours to get key activated.

2) Check .env for typos & syntax

.env is file which is used to hide credentials such as API_KEY in server side code.
make sure your .env file variables are using correct syntax which is
NAME=VALUE

API_KEY=djgkv43439d90bkckcs

no semicolon, quotes etc

3) Check request URL

check request url where API call will be made , make sure

It doesn't have spaces, braces etc
correct according to URL encoding
correct according to API documentation

4) Debug using dotenv:

to know if you dotenv package is parsing API key correctly use the following code

const result = dotenv.config()

if (result.error) {
  throw result.error
} 
console.log(result.parsed)

this code checks if .env file variables are being parsed, it will print API_KEY value if its been parsed otherwise will print error which occur while parsing.

Hopefully it helps :)

Must-know programming quotes

Muhammad Uzair — Wed, 12 Aug 2020 15:51:16 +0000

here is list of quotes by famous pioneers in field of computer programming 🔥

Premature optimization is the root of all evil 😈
Donald Knuth

Talk is cheap, show me the code😶
Linus Torvalds

Code never lies, comments sometimes do. 🙉
Ron Jaffries

Code is like humor when you have to explain it, it's bad
Cory House

Truth can only be found in one place : The Code
Robert C. Martin

First solve the problem then write the code
John Johnson

Think twice, code once
Waseem Latif

Add your favourite quote ⬇⬇