As all software developers, especially seniors, I was faced today with the task of making a simple, brain dead, design decision that I should be able to make in my sleep, but with every passing minute I came up with new designs and solutions to reach the same result so after spending 15 minutes thinking about it I got confused and the seemingly simple task became an important design choice.
For every problem, there is a solution that is simple, neat, and wrong. - H. L. Mencken
Let me walk you through what happened.
I was tasked with developing a solution to block some phone numbers (based on country codes) from receiving SMS from our APIs. The requirements are clear:
- have a configurable list of country codes
- validate the phone number against them
- throw a nice exception telling the user to use email instead of phone!
Starting off I began wondering where to store this list of country codes, the first option that came to my mind was: Store it in a configuration file. Easily editable and accessible, but then I remembered that we are hosted on AWS and are using IaC which means that to change the configuration file I'll need to push my infrastructure.
Back to my brain lab I thought about storing this list in a new DB table, simple, easy, straight forward, a table that contains a list of blocked countries with their codes, but worth it?
I gave it an extra minute….
Why not create a DB table with a list of all countries and add a flag to it specifying if the country is supported or not?
OR, another minute passes...
Why not create an application settings table (basically a configuration file stored in a DB table where each record is a key value pair) having an entry containing a list of these blocked countries…..
A simple task now needs a decision making chart of Pros and Cons
Even the most experienced amongst us will face this issue, a simple question a multitude of right answers! That's the job!
With great power comes great responsibility
Top comments (0)