Designing stateless distributed systems are relatively easy. You would have raised an event/message once the service had done processing. You typically are not worried about how the other systems consume your data. In fact in the majority of these scenarios, you don’t care what happens to the message/event after you were done.
Think of fire and forget. This could be easily achieved using typical message broker queues & topics. Sadly, this stateless approach is quite bookish and not practical for most enterprise application needs.
State could be as straightforward as an entity-update which another service is dependent on or a bit more trickier one as an amount being debited from one account and credited to another. …
CAP Theorem for data stores has been studied pretty well. The essential idea being, out of Consistency, Availability and Partition-Tolerance, a data store technology can choose either of two at any point in time. Example Cassandra chose A & P while Redis chose C & P, SQL Server went with C & A.
This perfectly fits well for data store technologies. You could decide which one technology to use based on service/application need.
For the family person (all roles — Dad/Mom/Husband/Wife) like me, you realize you could directly relate with your routines. Redefining CAP slightly,
C — Consistency/Quality in tasks.
A — Availability for tasks. …
Applying Blockchain to Event Sourcing
Event Sourcing pattern at the core requires an event store to maintain the events. What if we add these events as it arrives into a blockchain ? This should effectively make sure the events have not been tampered with. The plan would be to initiate typical blockchain mining after which the event is added to the “block-chain of events” — an “EventChain”.
The definite side effect is that until the mining is complete, the business transaction cannot be internally marked as complete. …
During an interesting discussion online on Mergers & Acquisitions, a basic question arose — if we consolidate technologies & tools used across the two merging companies, would it suffice most of the Architecture needs for the new company ?
Maybe; but in most cases, No.
A more formal approach is required to make sure we do not end up with a half cooked chowder served in a platinum goblet. …
It’s an interesting perspective to consider humans -
a. their interaction with others including animals & machines,
b. their growth & life-cycle
c. their evolution,
d. their anatomy
etc, could be treated as a reference Bible for software architectures.
Many of the observations have already been well adopted :
Mapping transactions, security, competing-consumers and related software patterns
Given a scenario for high load data day jobs that come in, how would a typical human handle it? How many humans would be required to handle it? …
We come across many instances in the software industry where “code-lumps” get deployed as software services/products with beautiful User Interface included to cover up all the ugliness underneath. The design document too looks fancy with usages of software patterns & practices neatly listed in the glossary.
After all this marketing stunt by the business, these modules are observed to have a rather short life-span. Before long, there are in-numerous critical issues being raised triggering its quick death. Sounds like a typical Start-Up story ?
In the majority of these cases, product owners were forced into releasing these “code-lumps” that just weren’t ready, while in other cases the anointed “architect” had no clues to why the “code-lumps” existed and why the patterns were chosen. At the first look, the software does appear to function as desired with all the components “working” great during those first pitch demos. …