Mind Map

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…

How to build a complex blockchain smart contract? What standard issues will you face with arrays, gas, different types of variables, deployment of contracts, etc? And how to solve them?

What is the right architecture for the app that should work with blockchain (and how it differs from traditional web architecture)? What libraries to use? How to configure environment?