Fuad Efendi

What do _._1 and _++_ mean in Scala? _._1 _1 is a method name. Specifically tuples have a method named _1, which returns the first element of the tuple. So _._1 < _._1 means “call the _1 method on both arguments and check whether the first is less than the second”. Example .toList.sortWith(_._1 < _._1) _._1 calls the method _1 on the wildcard parameter _, which gets the first element of a tuple.

Saga: a long story of heroic achievement, especially a medieval prose narrative in Old Norse or Old Icelandic. a long, involved story, or series of incidents. What is the “Saga” design pattern? A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. If a step fails, the saga executes compensating transactions that counteract the preceding transactions. A saga is a sequence of transactions that spans many services.

What is the “Database Sharding” design pattern? Data sharding pattern separates datasets into different shards or partitions. Each shard has the same schema but holds a distinct subset of the data. Sharding patterns improve scalability, as you can add new shards when the storage needs or depand for higher throughput increase; you can improve performance by reducing the workload of each service. What are the benefits and drawbacks of the “Database Sharding” microservices design pattern?

What is the “API Composition” design pattern? “API Composer” queries multiple services and aggregates results. Example: Elasticsearch has NRT (Near Real Time) search capabilities. Typical indexing (or optimmizing existing fragmented index) of large datasets will take hours; if we need to index latest tweets from Twitter in real-time, for past few hours only, we only need milliseconds, so that it is called NRT; and it supports near-real-time updates of the index and doesn’t need any “optimization”.

What is the “CQRS” design pattern? CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a datastore. CQRS separates reads and writes into different models, using commands to update data, and queries to read data. Commands should be business method oriented, such as “reserve funds”, “buy book”, “register user” Queries should never modify database Queries can use “materialized views” specifically optimized for reads; queries can be routed to “replica” as a performance optimmization “Command” can update First Name, Last Name, and DOB, and Query can return concatenated string “full name” and pre-calculated “age” What are the benefits and drawbacks of the “CQRS” microservices design pattern?

What is “Database Per Service” design pattern? Each microservice uses its’ own dedicated private persistence layer (database). This data can be accessed only via this dedicated microservice. A service’s (inernal) transactions only involve its own (internal, dedicated) database.

What is the “Domain Event” design pattern? Use domain events to explicitly implement side effects of changes within your domain. In DDD (Domain Driven Development) terminology, use domain events to explicitly implement side effects across multiple aggregates. For better scalability and less impact in database locks, use eventual consistency between aggregates within the same domain. An event is something that has happened in the past. A domain event is, something that happened in the domain that you want other parts of the same domain to be aware of.

What is the “Event Sourcing” design pattern? “Event Sourcing” persists the state of a business entity as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended to the list of events (to the log). The application reconstructs current state of the entity by replaying the events. What are the benefits and drawbacks of the “Event Sourcing” microservices design pattern? The benefits of the “Event Sourcing” pattern The drawbacks of the “Event Sourcing” pattern When to use “Event Sourcing” design pattern?

What is “Shared Database” design pattern? Few different services share the same persistence layer (database). The data is “shared” and different services need to implement for safe updates, cuncurrency, notifications, and so on. this pattern is primarily applicable for traditional “hard-to-scale” relational databases For example, “Department” service can add Employee to the Department, and “Employee” service can move Employee from one Department to another, and both services share the same traditional relational database with two tables Employee and Department.