Home

The Event-Driven model heavily relies on the QUALITY of events. Good quality events are: explicitly defined via contracts have comments support evolution with backward and forward compatibility support code generation breaking changes are well thought Good events are implemented using the right tools: use Avro/Thrift/Protobuf formats and never use JSON! use the right event broker (such as Pulsar) Good events are designed to: contain all the info needed by consumers use separate streams for each event type use the right data types for their fields (don’t use string for numbers, use enums, etc.

I accidentally met with the founders of EMPERA blockchain. As you may know, despite the fact that I believe in the blockchain future, I am a bit skeptical about new projects and ideas in this field as there are many pure scams and unprofessional enthusiasts. However, after reading all the papers and after a deep talk with the founders I am now very excited about this particular project. And I want to share with you my insights (as well as a few skeptical unclarities to be 100% honest).

Introduction into Event-driven microservice (EDM) architecture consists of the following topics: two topologies content of events three types of events table-stream duality schemas for defining event data single writer principle features of event broker event broker vs message broker single source of truth principle scaling using containers and VMs microservice taxes that we should pay These topics are disclosed in the Chapter 2 of the book we are currently studying:

Our company’s books club has selected a book about Microservices. It is “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare Chapter 1 contains intro info: Types of architectures and differences between them: Traditional monolith-style architectures Service-oriented architectures (SOAs) Event-driven microservice (EDM) architectures Levels of Communication Structures and related Conway’s Law: business implementation data Problems with traditional architectures (monolith & SOA) when you need to:

There are a number of businesses and business tasks when it is necessary to visually design, change and control the execution of business processes.

Large companies like SAP, IBM, Oracle play in this market and offer their heavy and expensive solutions.

But there is also a lighter and cheaper solution in this field.

Did you know that losing $1000 and then winning $900 (i.e. getting a result of -$100 in total) is more pleasant than winning $1000 and then losing $900 (i.e. getting a result of +$100 in total)!??

What has happened in the RECENT PAST drives our emotional response much more than how we are doing overall! It is a problem if you are making important prediction.

There are to ways to overcome this problem:

This is a continuation of my previous post Real Projects with Ethereum) - about how to setup a development infrastructure around real-life smart contract.

I’ve already told about the truthseeking group (The Buddy System) as a great way to improve decision-making process.

How to share information inside such a group and how to disagree efficiently (to find a good solution)? And how to communicate outside of such efficient group?

There is a set of rules called “CUDOS” that can be used for this…

People are not ready to consider themselves the source of the problem they are facing (their skill), they blame other people/circumstances (luck). How to overcome this issue?

One of the solution is to create “truth-seeking group” with your colleagues/friends/partners/“buddies”. And such a group should follow specific rules that would increase rationality…

Y Combinator’s motto is “Make Something People Want”. But how to find what people want? There are seven steps / considerations to gradually get closer to the answer…