Diego Pacheco Tech blog

Tradeoffs are key for design and architecture. Being able to run proper tradeoffs is an important skill you should master. Decisions we make in software should happen based on tradeoff analysis. Tradeoffs are about pros and cons, which can be done with a simple list of pros and cons. However it looks simple and easy, it is way harder than it looks. Running proper tradeoffs requires knolowsge of the domain, creativity, and lots of debate club skills. Tradeoffs are about trading one thing for another like speed vs. flexibility. Tradeoffs are about balancing factors that might not be attainable at the same time like consistency and availability. Without good tradeoffs skills, we can make wrong decisions and be fooling ourselves. Tradeoffs do not require fancy tools, we can do it with pen and paper, or any plaintext editor like vim. Before we do a deep dive into tradeoffs let's understand why they matter a lot. Why do Tradeoffs Matter? Tradeoffs matter for a variety of reasons: Better

Business domains can be very different due to the different natures of each business. Some domains are more static and allow us to easily understand them and produce an efficient core model. However, some business domains are very dynamic, and it is difficult to get the gist and essence of the domain. Some problems require the code to change all the time. The first thing that comes to mind is to externalize business rules either in the form of configuration or in the form of database tables. Externalization to configs and databases works well when the business rules are simple, however, when the business rules are complex, such externalization is more complex and tends to generate more complexity. Nothing is better than code to express complex ideas. Good domain modeling via proper OO design is a very powerful way to map and describe domains.

GraphQL makes a lot of sense for mobile applications. Especially when we consider poor networks. Aggregating data in one call is very powerful and makes a lot of sense for mobile. GraphQL allows a single interface for all operations for reads and writes. GraphQL is not that different from an API gateway or aggregation service. Selecting only the fields you need allows you to reduce the payload of requests, and latency resulting in improvements in the user experience via the mobile app. GraphQL has a lot of power and flexibility, which requires lots of attention to detail as well. Understanding the tradeoffs is important, one thing you are giving away by using only GraphQL is the ability to make multiple service calls in an asynchronous fashion, GraphQL is synchronous. GraphQL performance will have penalties . GraphQL never will be as fast as a modular monolith doing proper queries in the database. We can mitigate some performance issues by doing pre-loading, batching, or just caching

S3 is an object storage that scales within reasonable performance. S3 can be used for a variety of use cases like Big Data analytical workloads, data pipelines, and AI/ML pipelines. S3 is big in the data universe but is also used in services and microservices for a variety of other use cases like file sharing, document management, legal signatures, and many other use cases. S3 is not a relational database, however, from the isolation point of view , S3 should be seen in the same way we see data stores . Since 2020, S3 guarantee strong consistency Read-After-Write. S3 performance handle reads up to 5500 rps and 3500 rps for write. S3 is easy to use and reliable, now everything that is popular and useful can be misused. 

Distributed Monoliths are the worst. Nothing good comes from distributed monoliths. No one wants to have distributed monoliths, and still, they are very common in the industry. Complexity just gets bigger, our industry just gets more and more entangled. Complexity has everything to do with distributed monoliths. Distributed Monoliths are very complex, much more than monoliths. How can you avoid a trap? By definition, the only way is not to follow into the trap. Understanding the trap is how you can avoid it. However, some traps cannot be avoided because there are bigger forces like acquisitions, pandemics, economic downturns, wars, or time. Time can easily be the biggest trap of all. We need to learn how to work effectively with monoliths and distributed monoliths because they are to stay and we can't ignore them. Fishing monoliths is a long-turn battle, that requires persistence, patience, and allies. Let's start by understanding monoliths and Distributed Monoliths a bit more.

Internal shared Libraries are a trap . Sorry, not one trap, multiple traps because often there are multiple internal shared libraries. Engineers often take libraries for granted and fail to see the hidden costs in libraries. Libraries should be designed carefully . Libraries provide functionality, code reuse and allow us to be productive to some degree. I’m not against the usage of libraries. However, we need to understand that libraries have issues and hidden problems. For instance, productivity cannot be measured only on how fast you get things done in the sense of days, number of user stories, or releases. Several side effects need to be taken into account such as: Bugs: How many bugs did you produce by direct or indirect usage of a library. Incidents: If the bug creates a major incident, how much money did you lose, and how much your customers got affected? Any brand damage or loss of trust of your users? Debugging & Troubleshooting: How many hours, do teams spend debugging

Meetings are part of our day-by-day activities. All companies do meetings, which probably is the most common practice ever. However little is done to change or even improve such practice. How many times do you see people cleaning up meetings, meaning analytically and systemically removing meetings as a regular activity? During the 2020 pandemic, everything became a meeting resulting in a Zoom call. Do you want to troubleshoot some problem, you need a meeting, do you need to ask your friend how is he going, guess what? You need a meeting.