Irwan Hendra's Random Codes Blog

Optus Breach and Medibank Breach: A Breach Made in Hell  Problem: In the past few weeks there have been a whirlwind of data breach news from  Optus and then  Medibank . Anyone in Australia knows that these are two gigantic service providers in the country serving a huge portion of the population. Therefore the data stolen are horrendously massive, and when combined, extremely deadly. Let's have a look at Optus vs Medibank data stolen according to news:  As we can see, either data from Optus breach or Medibank breach alone provides ONE PRIMARY ID which is sufficient for a hacker to: Register a new phone number Open Buy Now Pay Later account Open crypto account in Centralized Exchange etc (not going to list all of them for security reason) To make things even worse, if someone got their hands on both of them and join them together: Basically they will produce a complete identity of a person with TWO PRIMARY ID  documents. With those documents, a hacker can: Access the victim bank ac

Transactional Outbox Pattern, Why? (part 1) Background In microservice and event driven architecture, transactional outbox pattern is crucial to maintain the state of data (or "aggregate" as per Domain Driven Design) in two or more persistent storages, especially when 2 Phase Commit is not available nor desired. You can read an excellent explanation of the pattern here . This article will be divided into two parts, part 1 will discuss why we need it, part 2 will discuss how we can implement it. In my experience designing solutions with transaction outbox pattern, I have come across multiple similar questions challenging why do we have to do it in such a complex way, and why can't we just reverse the order, use try catch clause, database transaction, etc. Based on those frequent conversations, here is my attempt to explain why we can't solve the problem with ordering, try catch clause or transactions. Suppose we have a system where we create a person record, which will