DEV Community: Pragyan Tripathi

Hiring a Company with a Few Lines of Code

Pragyan Tripathi — Wed, 14 Aug 2024 07:49:28 +0000

Remember when "There's an app for that" was the hottest phrase in tech?

Well, now it's "There's an API for that."

And it's changing everything about how we build products.

Here's why:

Focus beats generalization

API-first companies solve ONE problem really well.
Stripe? Payments. Twilio? Messaging. Plaid? Bank data.
They're not distracted by a million other things.
Their entire team is laser-focused on being the best at that ONE thing.

Scale creates magic

These companies serve thousands or millions of customers.
That means they can justify improvements that seem tiny but add up to an incredible product over time.
Plaid can integrate with even the smallest banks.
Why? Because across all their customers, thousands of people use that bank.

It's like hiring a whole company

When you use an API, you're not just getting a product.
You're getting an entire company working for you.
Imagine copying in some code and getting the Collison brothers to run your finance team.
That's what using Stripe is like.

The impact compounds

Just like hiring decisions, API choices compound over time.
For better or worse.
But at full company scale.

It's a product decision, not a purchasing one

Traditional SaaS? That's for department heads or execs.
APIs? That's for product and engineering.
The people building the product decide what to "hire."

Usage-based pricing aligns incentives

Most API companies charge based on usage.
Your costs scale with your business.
When you win, they win.
When you lose, they lose.

It's invisible to end-users

Your customers don't see the API.
They just see a product that works really well.
All the complexity is hidden behind a few lines of code.

The big question:

Does this make every company more efficient?

Or does it commoditize everything except core value props?

Probably both.

But one thing's for sure:

The way we build products will never be the same.

What do you think? Is the API revolution a net positive or negative for innovation?

API integrations are hard

Pragyan Tripathi — Tue, 13 Aug 2024 16:10:18 +0000

Most founders think product is everything.

They're wrong.

In today's SaaS world, integrations are the real game-changer.

Here's why:

Silos kill growth

• Standalone products are one-trick ponies.

• They can't leverage the ecosystem of best-in-class tools.

• Result? Limited value, limited growth.

Users demand connectivity

Modern users expect their tools to work together seamlessly.

They want:

• Reduced manual work.

• Custom workflows.

• Software that actually makes life easier.

• Integrations deliver this.

Data is the new oil

Integrations unlock powerful use cases:

• Headcount planning with accounting data.

• Revenue forecasting from CRM deal flows.

• Searchable company-wide file databases.

• Training data for next-gen SaaS LLMs.

But here's the kicker:

Most startups struggle to build and maintain integrations.

Why?

Building integrations is a nightmare:

• Deciphering complex API docs

• Manual data mapping

• Extensive coding

• High risk of errors

• It's not just hard. It's mission-critical.

Unreliable integrations = Business disaster

So why don't more startups prioritize integrations?

The product manager's dilemma:

Integrations vs. Core Features

It's a brutal trade-off:

Build integrations = Happy customers, but neglected product
Focus on core features = Strong product, but limited ecosystem

Both paths risk falling behind competitors.

The real problem?

Building robust integrations is expensive:

• Time

• Technical expertise

• Cross-company collaboration

These are precious resources for any startup.

The result?

Many companies settle for broken, unreliable integrations.

Or worse, no integrations at all.

But there's hope.

Smart founders are realizing:

Integrations aren't a "nice-to-have."

They're the foundation of long-term SaaS success.

𝘛𝘩𝘦 𝘸𝘪𝘯𝘯𝘦𝘳𝘴 𝘰𝘧 𝘵𝘰𝘮𝘰𝘳𝘳𝘰𝘸 𝘸𝘪𝘭𝘭 𝘣𝘦 𝘵𝘩𝘰𝘴𝘦 𝘸𝘩𝘰 𝘤𝘳𝘢𝘤𝘬 𝘵𝘩𝘦 𝘪𝘯𝘵𝘦𝘨𝘳𝘢𝘵𝘪𝘰𝘯 𝘤𝘰𝘥𝘦 𝘵𝘰𝘥𝘢𝘺.

Ready to simplify your API integrations? We're building Vade Studio, a no-code platform that makes it a breeze.

https://studio.vadelabs.com/

I deleted our database after 72 hours of no sleep.

Pragyan Tripathi — Mon, 12 Aug 2024 07:14:37 +0000

Early in my career I was tasked with migrating a database from MySQL to MongoDB.

I ran the migration, shifted the API to read data from MongoDB, unfortunately even after lots of testing, it didn't go as planned.

𝗧𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁?

Worked continuously for 72 hours to get things resolved and created a bigger blunder.

At the end of it, I was terrified.

But instead of getting fired, something shocking happened:

My team lead called a "blameless post-mortem."

We gathered to learn, not to point fingers.

This was my introduction to blameless culture. It changed everything.

𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝗳𝗼𝗿 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝘁𝗲𝗮𝗺𝘀:

Innovation thrives When devs aren't scared to fail, they take risks. That's where breakthroughs happen.
Real accountability emerges. No more finger-pointing. Just owning mistakes and fixing them.
Collaboration skyrockets. Problem-solving beats blame-gaming every time.
Morale goes through the roof. Mistakes become growth fuel, not career-killers.

𝗔𝘀 𝗮 𝘁𝗲𝗰𝗵 𝗹𝗲𝗮𝗱, 𝗵𝗲𝗿𝗲'𝘀 𝗵𝗼𝘄 𝗜 𝗯𝘂𝗶𝗹𝗱 𝘁𝗵𝗶𝘀 𝗰𝘂𝗹𝘁𝘂𝗿𝗲:

I air my dirty laundry. I talk openly about my screw-ups. It sets the tone.
We throw "failure parties". We celebrate what we learn from face-plants.
Post-mortems are sacred. Regular, blame-free incident analysis. Focus on systems, not scapegoats.
We hunt root causes relentlessly. Band-aids are for paper cuts. We fix the core issues.

The result?

A team that moves fast, innovates fearlessly and actually enjoys coming to work.

Shocking, I know. 🙄

What about your company?

Is failure a firing offense or a learning opportunity?

I'd love to hear your stories. Drop them in the comments.

After Gemini, here's Meta's attempt to fool us 👎

Pragyan Tripathi — Fri, 09 Aug 2024 06:21:44 +0000

Last week, Meta announced their new LLM, Llama 3.1, claiming it rivals closed-source models like GPT-4 and Claude 3.5.

They used popular benchmarks like MMLU (massive multi-task language understanding) to back up their claims.

But here's the problem:

These benchmarks are fundamentally flawed.

Here's why:

They're too easy

MMLU was created in 2020. Back then, most models scored around 25%.

Now? The best models score 88-90%.

It's like grading high school students on middle school tests.

They contain errors

A study found that 57% of MMLU's virology questions had errors.

26% of logical fallacy questions were wrong too.

Some had no correct answer. Others had multiple right answers.

Models might be cheating

LLMs are trained on internet data. This often includes benchmark questions and answers.

Models could be "contaminated" - they've seen the test in advance.

Some companies might even deliberately train on benchmark data to boost scores.

Small changes have big impacts

Asking an AI to state an answer directly vs. giving a letter/number can produce different results.

This affects reproducibility and comparability.

They don't reflect real-world performance

Benchmark scores often fail to match how models perform on actual tasks.

Companies use inflated scores to hype products and boost valuations.

So what's the solution?

Create harder benchmarks.

↳ MMLU-Pro, GPQA, and MuSR are examples of tougher tests.

Use automated testing systems

↳ HELM(holistic evaluation of language models) and EleutherAI Harness generate more trustworthy leaderboards.

Develop new benchmarks for emerging skills

↳ GAIA tests real-world problem-solving. NoCha(novel challenge) assesses long-context understanding.

Use AI to create benchmarks

↳ Projects like AutoBencher use LLMs to develop new tests.

Focus on safety benchmarks

↳ Anthropic is funding the creation of benchmarks to assess AI safety risks.

The big picture:

As AI commercializes, we need reliable, specific benchmarks.

Startups specializing in AI evaluation are emerging.

The era of AI labs grading their own homework is ending.

And that's a good thing for everyone.

How to Ask Technical Questions (And Actually Get Answers)

Pragyan Tripathi — Thu, 08 Aug 2024 07:31:58 +0000

I see it all the time:

Newbies ask terrible questions, and then wonder why they get ignored.

Experienced devs getting frustrated by low-effort queries.

Here's the truth: Asking good technical questions is a skill.

Master it, and you'll get better answers, faster.

Here are 5 key principles for asking effective questions:

Do your homework first Before asking, exhaust these options:

• Search forums/mailing lists
• Google it
• Read the manual/FAQ
• Experiment yourself

𝗦𝗵𝗼𝘄 𝘆𝗼𝘂𝗿 𝘄𝗼𝗿𝗸. 𝗦𝗺𝗮𝗿𝘁 𝗵𝗲𝗹𝗽𝗲𝗿𝘀 𝗰𝗮𝗻 𝘀𝗽𝗼𝘁 𝗹𝗮𝘇𝘆 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻-𝗮𝘀𝗸𝗲𝗿𝘀 𝗶𝗻𝘀𝘁𝗮𝗻𝘁𝗹𝘆.

Be specific and informative

• Describe symptoms precisely
• Include environment details (OS, versions, etc)
• Show exact steps to reproduce
• Provide relevant logs/output

𝗩𝗮𝗴𝘂𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 𝗴𝗲𝘁 𝘃𝗮𝗴𝘂𝗲 𝗮𝗻𝘀𝘄𝗲𝗿𝘀 (𝗼𝗿 𝗻𝗼𝗻𝗲 𝗮𝘁 𝗮𝗹𝗹).

Format for readability

• Break into short paragraphs
• Use syntax highlighting for code
• Proofread for typos/grammar

𝗠𝗮𝗸𝗲 𝗶𝘁 𝗲𝗮𝘀𝘆 𝗳𝗼𝗿 𝗯𝘂𝘀𝘆 𝗲𝘅𝗽𝗲𝗿𝘁𝘀 𝘁𝗼 𝗵𝗲𝗹𝗽 𝘆𝗼𝘂.

Ask about the problem, not your solution Explain what you're trying to accomplish, not just the roadblock you've hit.

𝗬𝗼𝘂 𝗺𝗶𝗴𝗵𝘁 𝗯𝗲 𝗼𝗻 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝗽𝗮𝘁𝗵 𝗲𝗻𝘁𝗶𝗿𝗲𝗹𝘆.

Follow up and say thanks

• Let helpers know the outcome
• Summarize the solution for others
• Express gratitude

𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗴𝗼𝗼𝗱𝘄𝗶𝗹𝗹 𝗽𝗮𝘆𝘀 𝗱𝗶𝘃𝗶𝗱𝗲𝗻𝗱𝘀.

Remember: Experts' time is valuable. Asking good questions shows respect and increases your chances of getting help.

Bad: "𝘔𝘺 𝘤𝘰𝘥𝘦 𝘥𝘰𝘦𝘴𝘯'𝘵 𝘸𝘰𝘳𝘬. 𝘏𝘦𝘭𝘱!"

Good: "𝘐'𝘮 𝘵𝘳𝘺𝘪𝘯𝘨 𝘵𝘰 𝘪𝘮𝘱𝘭𝘦𝘮𝘦𝘯𝘵 𝘟. 𝘏𝘦𝘳𝘦'𝘴 𝘮𝘺 𝘤𝘶𝘳𝘳𝘦𝘯𝘵 𝘤𝘰𝘥𝘦 𝘢𝘯𝘥 𝘵𝘩𝘦 𝘦𝘹𝘢𝘤𝘵 𝘦𝘳𝘳𝘰𝘳 𝘐'𝘮 𝘴𝘦𝘦𝘪𝘯𝘨. 𝘐'𝘷𝘦 𝘢𝘭𝘳𝘦𝘢𝘥𝘺 𝘵𝘳𝘪𝘦𝘥 𝘈, 𝘉, 𝘢𝘯𝘥 𝘊..."

𝗠𝗮𝘀𝘁𝗲𝗿 𝘁𝗵𝗲 𝗮𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝘄𝗮𝘁𝗰𝗵 𝘆𝗼𝘂𝗿 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 𝘀𝗸𝗶𝗹𝗹𝘀 𝘀𝗼𝗮𝗿.

Agree? Disagree? What's your best tip for asking technical questions effectively?

Why I chose Clojure/Script for building Vade Studio

Pragyan Tripathi — Wed, 07 Aug 2024 12:33:37 +0000

Why I chose Clojure/Script for building Vade Studio

In 2022, I started with a big vision: one platform to build SaaS applications. Today's no-code space is fragmented.

You need 10+ tools to get a simple SaaS product working.

I wanted to change that.

My constraints were clear

• Build and customize UI

• Integrate with diverse data sources

• Create workflows, and chain APIs together

• Deploy the app into secure and reliable infrastructure

• Out of the box monitoring and alerting

• Extend the platform through code and pre-built modules

First attempt: NodeJS + React.

Got a basic version in 3 months. But the code? Bloated.

Backend workflows? Slow as molasses.

Tried Python backend. Still messy.

As a solo dev, the context switching was killing me.

No cohesion. Tons of config. Python classes everywhere.

5.Considered Go. Didn't feel right.

Then I watched Rich Hickey's "Simple Made Easy."

Lightbulb moment:

I needed a language that works WITH data, not against it.

Started building basic functionality in Clojure.

The results were staggering. .

• Same functionality 100X less code.

•Here's what made Clojure Vade Studio's super power:

• Multi Methods: The secret sauce for our data-driven backend and UI.

• Pathom: Simplified data retrieval across multiple sources.

• Interceptors: Powering our workflow engine with elegance.

• Fulcro: Revolutionized our approach to full-stack development.

• Macros: The game changer for our compiler

• REPL: Rapid experimentation and testing.

The Clojure community? Top-notch

They teach you to think in ways you never thought possible.

Their focus on simplicity and data-centric design aligned perfectly with my vision

𝗧𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁𝘀 𝘀𝗽𝗲𝗮𝗸 𝗳𝗼𝗿 𝘁𝗵𝗲𝗺𝘀𝗲𝗹𝘃𝗲𝘀:

• Our entire codebase - just 20000 lines of code

• No more context switching (Clojure Backend, ClojureScript Frontend)

• Leverage NodeJS, JS, and Java ecosystem whenever needed.

• Number of developers - 3

𝗧𝗵𝗲 𝗹𝗲𝘀𝘀𝗼𝗻?

Sometimes the right tool changes everything.
For us, that tool was Clojure.
It didn't just solve our problems – it redefined what was possible.

PS: Are you curious about what we've built? Checkout preview version at https://studio.vadelabs.com

3rd Party API integration

Pragyan Tripathi — Tue, 06 Aug 2024 09:19:57 +0000

As a tech founder, I've dealt with "𝙞𝙣𝙩𝙚𝙜𝙧𝙖𝙩𝙞𝙤𝙣 𝙝𝙚𝙡𝙡" so many times, I've lost count.

Getting it right is so hard. Spending hours pouring over documentation, writing code, and troubleshooting errors, led to my burnout.

But why do we put ourselves through this? Why do we need to connect to multiple 3rd party APIs just to build a simple SaaS?

The answer is simple: our customers demand it. They want seamless integrations with their favorite tools and platforms. They want to use our SaaS with ease, without having to worry about the technical complexities behind the scenes.

𝗧𝗵𝗲 𝗡𝗶𝗴𝗵𝘁𝗺𝗮𝗿𝗲 𝗶𝘀 𝗥𝗲𝗮𝗹

Reading documentation that's longer than a Game of thrones novel.
Writing code that's more complicated than a calculus problem.
Monitoring errors that seem to pop up out of nowhere.
Handling rate limits that are more restrictive than a dictator's regime.
Dealing with API changes that break your entire integration.
And don't even get me started on the security and compliance headaches. that come with each new integration!

Developers today, want to build rockets and Teslas of tomorrow. However, we're stuck in this rut of API integrations. We're stuck in a never-ending cycle of debugging, troubleshooting, and hair-pulling frustrations.

Zomato's new 'District' app wants to be your go-to for everything "going out" in India.

Pragyan Tripathi — Mon, 05 Aug 2024 06:01:41 +0000

Zomato's new 'District' app wants to be your go-to for everything "going out" in India.

Here's why it's a big deal:

Zomato already owns your "stay at home" experience.
Food delivery? Check. Grocery delivery with Blinkit? Check.
Now they're coming for your nights out.
They're not starting from zero.
Zomato's dining-out business is already doing $500M in annual GMV.
And it's profitable.
But here's the real kicker:
They're going after BookMyShow's 60% market share in event ticketing.
That's ballsy.
The plan? One app to rule them all.
Restaurants, movies, sports, concerts - all in 'District'.
This isn't just another feature.
Deepinder Goyal (Zomato's CEO) thinks this could be their third major B2C business.
That's huge.

But here's where it gets tricky:

Indian users hate app clutter.
They don't want 20 different apps for 20 different things.
But they also hate bloated "super apps" that try to do everything.
It's a tightrope walk.
Success depends entirely on the offline experience.
Zomato knows food delivery.
But can they make your night out amazing?That's a whole different game.
Early adopters might score big.
Remember when Zomato was giving away free food delivery?
Expect massive subsidies to get people hooked on 'District'.
The real test: Can they change habits?
Today, you don't think twice about paying ₹50 for food delivery.
Can they do the same for event bookings?

My take:

This could be Zomato's biggest move yet.
Or it could be a massive distraction from their core business.
Either way, I wouldn't bet against Deepinder Goyal.
He's turned Zomato and Blinkit into a beast.
And 'District' might just be his next big win.
**
What do you think?**

Is 'District' the future of "going out" in India? Or

Is Zomato biting off more than it can chew?

6 more Rules that will help you write secure, scalable and adaptable programs

Pragyan Tripathi — Fri, 23 Jun 2023 01:31:00 +0000

“Programming isn’t about what you know; it’s about what you can figure out.”- Chris Pine

6 more Rules that will help you write secure, scalable and adaptable programs:

1. Avoid overcrowding your message bus:

Don't publish everything. Sample traffic to ensure alignment between cost and value. Eliminate low-value, high-cost traffic. Sample low-value/low-cost and high-value/high-cost traffic to reduce the cost.

2. Be wary of scaling through third parties:

Do not rely on vendor products, services, or features to scale your system. Keep your architecture simple and keep your costs in control. It can be violated by using a vendor’s proprietary scaling solution.

3. Purge, archive, and cost-justify storage:

Apply recency, frequency, and monetization analysis to determine the value of the data. Match storage costs to data value. It is important to understand and calculate the value of your data and to match storage costs to that value.

4. Remove business intelligence from transaction processing:

Separate business systems from product systems and product intelligence from database systems. Remove stored procedures from the database and put them in your application logic.

5. Design your application to be monitored:

Think about how you will need to monitor your application as you are designing it. Build hooks into your system to record transaction times. Adopt as an architectural principle that your application must be monitored.

6. Be competent:

Be competent, or buy competency in/for each component of your architecture. Identify the team responsible and the level of competency with that component. You can also buy solutions and be competent in their deployment and maintenance.

The earlier 40 rules: Link

Thanks for reading this.

If you have an idea and want to build your product around it, schedule a call with me.

If you want to learn more about DevOps and Backend space, follow me.

If you want to connect, reach out to me on Twitter and LinkedIn.

10 more Rules that will help you write secure, scalable and adaptable programs

Pragyan Tripathi — Thu, 22 Jun 2023 01:31:00 +0000

Bad programmers worry about the code. Good programmers worry about data structures and their relationships. - Linus Torvalds

10 more Rules that will help you write secure, scalable and adaptable programs:

1. Don't select everything:

Selecting everything in a query is prone to break things when the table structure changes and it transfers unneeded data. Don't use wildcards when selecting or inserting data.

2. Implement fault isolation or swimlanes in your designs:

It consists of eliminating synchronous calls between fault isolation domains, limiting asynchronous calls and handling synchronous call failure, and eliminating the sharing of services and data between swimlanes.

3. Never trust a single point of failure:

Strive for active/active rather than active/passive solutions. Use load balancers to balance traffic across instances of a service. Use control services with active/passive instances for patterns that require singletons.

4. Avoid putting systems in series:

Avoid adding components to your system that are connected in series. When necessary to do so add multiple versions of that component so that if one fails others are available to take its place.

5. Ensure you can wire on and off functions:

Develop shared libraries to allow automatic or on-demand enabling and disabling of services. Implement Wire On/Wire Off Frameworks. Work to develop shared libraries that can be reused to lower the cost of future implementation.

6. Strive for statelessness:

Choose stateless implementations whenever possible. If stateful implementations are warranted for business reasons, always push back on the need for a state in any system. Use business metrics and multivariate (or A/B) testing to determine whether state in an application truly results in the expected user behavior and business value.

7. Maintain sessions in the browser when possible:

Using cookies to store session data is a common approach and has advantages in terms of ease of scale but also has some drawbacks. Note that unsecured cookies can easily be captured and used to log into people’s accounts.

8. Make use of a distributed cache for states:

Many web servers or languages offer simple server-based session management but are often fraught with the problem of user affiliation with specific servers. Implementing a distributed cache allows you to store session data in your system and continue to scale.

9. Communicate asynchronously as much as possible:

Use asynchronous communication techniques to ensure that each service and tier is as independent as possible. This allows the system to scale much farther than if all components are closely coupled together.

10. Ensure your message bus can scale:

Message busses can fail from demand like any other physical or logical system. They need to be scaled. Treat message busses like any other critical component of your system. Scale them ahead of demand.

The earlier 30 rules: Link

Thanks for reading this.

If you have an idea and want to build your product around it, schedule a call with me.

If you want to learn more about DevOps and Backend space, follow me.

If you want to connect, reach out to me on Twitter and LinkedIn.

8 tasks you need to do for your team as an Engineering Manager (EM)

Pragyan Tripathi — Wed, 21 Jun 2023 01:31:00 +0000

The role of an Engineering Manager is both challenging and rewarding.

8 tasks you need to do for your team as an Engineering Manager (EM):

Daily Standups
Unblocking the team
One to Ones
Recruiting
Administrative stuff
A bit of coding (may be)
Meetings with managers and stakeholders
Project Management

Thanks for reading this.

If you have an idea and want to build your product around it, schedule a call with me.

If you want to learn more about DevOps and Backend space, follow me.

If you want to connect, reach out to me on Twitter and LinkedIn.

10 more Rules that will help you build secure, scalable and adaptable applications

Pragyan Tripathi — Tue, 20 Jun 2023 01:32:00 +0000

The function of a good software is to make the complex appear to be simple. - Grady Booch

10 more Rules that will help you write secure, scalable and adaptable programs:

1. Use Expires Headers:

For each object type (IMAGE, HTML, CSS, PHP, and so on) consider how long the object can be cached and implement the appropriate header for that timeframe.

2. Leverage Page Caches:

Decrease load on Web servers by caching and delivering previously generated dynamic requests and quickly answering calls for static objects. Page caches are a great way to offload dynamic requests and to scale cost-effectively.

3. Learn Aggressively:

Watch your customers or use A/B testing to determine what works. Use postmortems to learn from incidents and problems in production. Be constantly and aggressively learning.

4. Don't rely on QA to find mistakes:

QA doesn’t increase the quality of your system, as you can’t test quality into a system. If used properly, it can increase your productivity while decreasing costs.

5. Failing to design for rollback is designing for failure:

Don’t accept that the application is too complex or that you release code too often as excuses that you can’t roll back. No sane engineer would roll code that they could not pull back off in an emergency.

6. Discuss and learn from failures:

Employ a postmortem process and hypothesize failures in low-failure environments. Learn from everyone and identify the technology, people, and process issues that need to be corrected.

7. Be aware of costly relationships:

Think about database splits and possible future data needs as you design the data model. The cost of fixing a broken data model after it has been implemented is likely 100x as much as fixing it during the design phase.

8. Use the right type of database lock:

Understand the types of locks and manage their usage to maximize database throughput and concurrency. Change lock types to get better utilization of databases and look to split schemas or distribute databases as you grow.

9. Pass on using multi-phase commits:

Do not use multiphase commit protocols as a simple way to extend the life of your monolithic database. It will likely cause it to scale even less and result in an even earlier demise of your system.

10. Try not to use "SELECT FOR UPDATE":

Cursors are powerful constructs that, when properly used, can make programming faster and easier while speeding up transactions. But FOR UPDATE cursors may cause long-held locks and slow transactions.

The earlier 20 rules: Link

Thanks for reading this.

If you have an idea and want to build your product around it, schedule a call with me.

If you want to learn more about DevOps and Backend space, follow me.

If you want to connect, reach out to me on Twitter and LinkedIn.