It is just not about redundancy. In this post I cover how having more AZs mean you need fewer nodes to achieve higher availability.

Reading other people’s code is a sure-fire way to improve as a developer. But what about as a database designer? The same process applies!

This post by Shekhar Gulati is him sharing what he learned by applying that principle to GitLab’s schema.

I learnt a lot from the GitLab schema. They don’t blindly apply the same practices to all the table designs. Each table makes the best decision based on its purpose, the kind of data it stores, and its rate of growth.

More posts like this, please!

In this post, I will talk about important factors you should consider when architecting systems that are powered by third-party systems. The factors I detail are:

1. deployment model
2. technology coherence
3. NFRs and SLAs
4. Infrastructure and hardware needs
5. API style and documentation
6. Idempotent APIs
7. Getting data out of the third party provider
8. Community

This post covers 5 cases where the author uses the JSON data type for column definitions:

• Dumping request data for later processing
• Supporting extra fields
• Some one-to-many relationships
• Key-value use cases
• Simpler EAV design

Craig Kerstiens has also weighed in on this topic for us.

In this post, I expand upon Michael Nygard’s post Documenting Architecture Decisions. Michael defines architecturally significant decisions as those decisions that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques. I add examples to each of the five decisions categories.

In this post, I cover in a step by step manner how to do software estimation for project bids where there is limited clarity and a lot of ambiguity. I cover how we can use an uncertainty factor to cover the unknowns, questions/things to ask/consider at each step of the software estimation process, and some practical advice. This process is based on estimates I have done for multiple projects in the last couple of years.

Most software companies have to make decisions on whether to build a custom software or buy it from a vendor. In the last year I read many good articles on the web that helped shape my thoughts on how to approach these discussions. This article lists of questions that I have started to use to understand and make these decisions.

Sometimes you can’t make an informed decision because you don’t even know what should factor in to that decision. Shekhar Gulati is here to help provide those factors and he even produced this handy decision matrix for you.

Shekhar Gulati does a quick retro after his first year as CTO. Their lessons include:

• Schedule time for yourself
• Getting things done without doing them
• You will not have all the answers
• Pick your battle wisely

And a few more.