Diego Pacheco Tech blog

If you look up on dictionary.com the first two definitions of state are: the condition of a person or thing, as with respect to circumstances or attributes: a state of health. The condition of matter with respect to structure, form, constitution, phase, or the like: water in a gaseous state. Software is all about data, which is the state. The state could be your basic data, such as your name, last name, address, phone, email, bank account ID, or any other IDs and information you might have. Buying software has many side effects, many of which  are negative . Such data needs to be captured somewhere, usually in a relational database. But it could be in any other data store like a NoSQL Database like Cassandra, a K/V store like Redis, or an object store like S3. Ideally, the state should be contained and even isolated. However, in distributed systems, we often need a distributed state. The state is necessary. However, we might create additional complexity if we don't deal with the s...

Service contract design is hard. People do it all the time, but it is not always correct. Most of the time, engineers pay more attention to the service's internal implementation than the contract. A Service contract is the most important part of a service. A good contract provides an abstraction that allows us to have flexibility and allow future refactoring without impacting clients. Being able to refactor code without breaking consumers is pure gold. It's priceless. Not all industries are the same; however, the more dynamic and agile the industry is, the more you need to be able to do Refactoring. To do refactoring more often, you need to make decisions that allow refactoring to happen at a lower cost. If the price of refactoring is always high, no refactoring will happen, and that is game over; that is how we create inadequate legacy systems. A service contract provides a high level of abstraction(ideally) or might(if they do a poor job) leak internal implementation details....

We are in the holiday season. You walk into any Starbucks and see the Christmas decorations. Lights and Christmas trees are everywhere, and the advent of code is still rolling. Whether Xmas is summer or winter, You can get some specials and flavors only on Xmas. Now, you must wonder if this is a technical blog post; yes, 100% it is. I promise there will be a point at the end. Let's imagine a very different coffee shop experience; in reality, it's not how I will describe it, but hopefully, it will help you to see my point. I'm pretty sure you've gone to a coffee shop before; how it works is simple: you look many for what coffee + snacks you want, you get in line, pay at the cashier, and then the barista will brew you coffee, warm your food, and you will be good to go. If it is a good place, they will call you by name. Now, let's imagine a very different experience. Consider this the upside-down Xmas experience. However, if you want to name it, I will give you my nam...

Distributed Monoliths are the predominant form of modern legacy systems. Sometimes distributed monoliths are created by teams misapplying microservices architecture due to lack of isolation or internally shared libraries break of isolation. Other times, there is just the proverbial no time to refactor. Let's share the database. However, sometimes distributed monoliths happen due to non-obvious reasons from decisions that, at first glance, sound like good ideas and are even far away from engineering.  In software, we often run a trade-off analysis, Build vs Buy, where we must decide whether to build or buy software. Buying is usually attractive because it gives some speed (since you don't need to code it). Building, of course, takes longer, and you will need to maintain it; there is a chance of the project failing, and you invest money and have no software. There are trade-offs between building and buying. However, people often think buying has no implications and is much better...