See Glia Announcement on Generative AI Solutions; GVAs are turn-key AI assistants built specifically for financial institutions, automating routine services and sales interactions

Glia Surpasses AI Leadership Milestone in Financial Services with 100+ Glia Virtual Assistant Customers

The TDC, as it’s known in the Keys, was created in the 1980s to promote Florida Keys tourism. The public agency has a multi-million dollar annual budget and contracts with an advertising firm, a public relations firm and a group of photographers and production crews.

Florida Keys tourism agency under scrutiny for possible money mismanagement. What to know

M any people are joining the gig economy these days, and it's easy to see why. There are more options than ever when it comes to using your skills and resources to become your own boss and enjoy the flexibility that comes with gig employment.

3 Financial Habits That Help Gig Workers Thrive

Though many of us have dreamed about having millions of dollars, we probably don't fantasize about how to manage that money for taxes. Self-made millionaires have to think about their earnings,

I’m a Self-Made Millionaire: 3 Money Steps I Take at the End of Every Year

Financial planners have seen it all while working with clients-from financial ruin to financial freedom. Over the years, they’ve learned what separates millionaires from those who struggle to get their monetary footing. I’m a Self-Made Millionaire ...

13 Lessons From Millionaires That Financial Planners Use To Help Others Get Rich

If you're going freelance, your financial life is likely to get more complex. Take a look at three things in particular you need to know.

3 Important Financial Lessons I've Learned as a Freelance Worker

Prioritizing self-care and achieving financial stability can alleviate stress and create the conditions for happiness to flourish. Strong connections with family and friends provide emotional support, belonging, and happiness. Nurturing these relationships ...

Find Inner Peace: 15 Simple Tips to Stop Worrying About the Little Things!

My Financial Advisor said the common thread among his wealthiest clients is that they're hard workers. They're not Mensa members with superhuman intelligence, people who inherited millions or those who simply got lucky with one random startup idea that took off like wildfire with little to no effort -- though those, two, are paths to wealth.

I Asked My 7-Figure Financial Adviser What His Self-Made Millionaire Clients Have in Common

If you're serious about leveling up your financial game, tuning in to Grant Cardone's teachings can be a game-changer. Cardone is a powerhouse entrepreneur, trainer, author and motivational

Grant Cardone Shares 10 Steps To Becoming a Self-Made Millionaire

A loss of services or, ultimately, a loss of the hospital itself would be just absolutely detrimental to this community.”

How a Connecticut hospital became a shell of its former self, a ‘dire situation.’

Self Financial

self-lender

TL;DR: A self-leader does everything that a leader should do, but for herself. She plans, motivates, listens, and cares for herself. She uses the S.A.M. framework to put her efforts into perspective by focussing on Skills, Attitude, and Mindfulness as the core of her self-leadership practice. hat comes to your mind when you think of leadership? W What do leaders really do? Whether you're thinking about your favorite football club captain, a community leader, or Nelson Mandela, leaders across the board and abilities. share certain characteristics , and help their followers grow. They delegate, push, and pull, and take the long term view, as well as jump into action in the short term. They seem like super heros who have no time for self-doubt or procrastination. Leaders coach, guide, plan, listen to others If that's what marks a leader, what does a do? self-leader A self-leader does everything that a leader does, but for one-self. That's it. If you wish to be a self-leader, you would need to do all that a leader does, for yourself. You will have to: > Craft a vision for yourself > Listen to yourself > Plan your growth > Facilitate your journey > Motivate yourself > Keep the big picture in mind > Be driven by your purpose > Show long-term commitment When was the last time you clarified your purpose? Have you been taking time to ? How do you motivate yourself when everything seems to be falling apart? reflect and refine your plans Take your time to check-in with yourself, and reaffirm your commitment. Once you're ready to take on the burden of self-leadership, read on. S.A.M. a simple framework for self-leadership Now that you've decided to be your own leader, it's time to decide what you want to work on. I suggest looking at the following three avenues for growth: the things you can do, like planning, listening, writing an article Skills: the energy you put into your action, like joy, curiosity, helpfulness Attitude: the quality of your awareness, focus, perspective Mindfulness: S.A.M. gives a simple framework for self-evaluation and focussing your development journey.  If there's anything you can improve on one of these three topics, you'll be well on your way as a self-leader. Let's look at each of them in a bit more detail. Skills A leader l istens, plans, facilitates, puts things into perspective, and works hard... What skills do you want to develop? Which ones will help you take your work and life to the next level? Attitude A leader is authentic, sincere, helpful, curious, joyful... Have you mastered these attitudes? Is there one that stands out above others? How would you like people to describe your attitude? Pick one to work on! Mindfulness A mindful leader is aware, stress-free, caring, non-judgemental, and attentive... How will you use mindfulness? Would you like to be more mindful, in order to reduce stress, or make better decisions, improve your attention span, or...? Self-leadership is a unique journey and . There are no right and wrong answers, and the path will always be unpredictable. only you can decide what to focus on While SAM will help you give focus to your self-leadership journey, only you can provide the over-arching purpose. It is that purpose that will keep you going and get you through the toughest of times. I wish you all the joy and success in the world on this journey! How do you lead yourself? Know anyone who fits this description? Share in the comments or ;) find me on twitter Previously published at https://medium.com/@balach/self-leadership-for-dummies-turbo-charge-your-work-life-1de77b7c1127

Introducing S.A.M.: The Self-leadership Framework

121 Stories To Learn About Personal Growth

In the previous , we discussed how to create a Distributed Data Store or more precisely a replicated one. It made the data store more available, at least allowing for more reads simultaneously. However, this approach isn’t perfect for any case, especially when we have to store and query large amounts of . For this, we need a partitioned (or sharded) data store. article data Content Overview Problem Formulation Partitioned Data Stores Partitioning by Key Range Partitioning by Hash of Key Rebalancing and Consistency Hashing Two Partitions per Node Python Implementation Conclusion Problem Formulation We have a copy of data per node in the replication data store. Suppose we have 3 nodes in our distributed data store. Also for simplicity, we note the whole amount of data stored as D. Then our Distributed Data Store takes 3D of memory. This becomes impractical when we have a lot of data and heavy queries (especially write ones). This is illustrated in Figure 1. Partitioned Data Stores By Partitioning some data you split it into groups that we usually name partitioned or partitions. To each node is assigned one or more partitions, making it serve only these partitions. For example, if we assign to each node a single partition, in our three-node example, then we need only D of memory, but if we assign 2 partitions to each node, then we store in total 2/3 D. This process is illustrated below: But now arise a question. How do we decide to which partition a piece of data belongs? There are some strategies. Partitioning by Key Range Suppose all records in the data store have as an id an integer number. Then we can set partitions as ranges, for example, 0-999, 1000-1999, 2000-2999, and so on. Then using the id we can find the range and redirect the request to the node(s) serving these ranges. To node that partition can also be used when ids are strings, and the first n letters of the id can define the partition. However, this approach can lead to hot spots - when one or a couple of partitions are more accessed than others. This can put down a node or two. To avoid this case we can use Partitioning by Hash of Key. Partitioning by Hash of Key To reduce the risk of hot spots, distributed data stores often use a hash function to determine the partition for a given key or index. Hash functions are used to make skewed data and make it uniformly distributed. If we have for example a 32-bit hash function, then the string taken will be converted into a seemingly random number between 0 and 2^23 - 1. In such a way even very similar strings have evenly distributed hashes. Usually just having the hash of the index or key isn’t enough. Also, we do the following operation: hash mod p Where p is the number of partitions. It’s important to mention that the number of nodes and partitions can be different. In this way, we find the partition to forward the request. However, there is a problem that also should be solved - rebalancing. Rebalancing and Consistency Hashing As usual, in distributed systems can happen anything. For example one of the nodes from the distributed data store can fall, and its partitions will be lost. Or a new machine is added to the cluster, how then do we know which partition(s) to assign to it? Consistency Hashing is a way to solve the problem of rebalancing. Initially, we need to place all our services in an imaginary circle at an equal distance from each other as shown in the image below. Then we assign to each service an angle - in our example: Service A: 120; Service B: 240; Service C: 360; Then when we get a request we compute the hash mod 360 and find the node with the lowest difference between its assigned degree and the value that we get. This structure is called the Hash Ring and when a new node is added it just assigns itself a partition (or an angle) and starts to process requests. When a node falls then his angle value just isn’t used anymore for computing the partition. Two partitions per node In the example that we are going to implement below, we are going to have 2 partitions per node. In this case, even if one node falls the data that it was storing can be found in the rest of the nodes. We are going to do that by searching the two nearest angles from the service from the hash mod 360. This is illustrated below: Python Implementation To implement the sharded data store we are going to change a little bit the code from the last article. Shortly are going to add the CRUDUser to the capacity to compute the hash mod 360 of the index of the user and find the nodes responsible for the request. Changes to the main.py First, to the credentials of the service, we are going to add a new value - degree - this is the partition the service is responsible for: # Defining the service credentials.
service_info = {
    "host" : "127.0.0.1",
    "port" : 8000,
    "leader" : True,
    "degree" : 120
}

# Defining the followers credentials.
followers = [
    {
        "host" : "127.0.0.1",
        "port" : 8001,
        "degree" : 240
    },
    {
        "host" : "127.0.0.1",
        "port" : 8002,
        "degree" : 360
    }
] As you can see this value is added to the dictionary with the followers’ credentials too. sRefactoring of the CRUDUser Class Now CRUDUser class should be refactored to be able to use the sharding capacity. We are going to start with adapting the constructor, namely adding the service degree to the CRUDUser: class CRUDUser:
    def __init__(self, leader : bool, degree : int, followers : dict = None) -> None:
        '''
            The constructor of the CRUD class.
        :param leader: bool
            True fro leader and False for follower.
        :param degree: int
            The degree for which the service is responsible.
        :param followers: dict, default = None
            The dictionary with the followers credentials.
        '''
        self.users = {}
        self.leader = leader
        self.deegree = degree
        if self.leader:
            self.followers = followers Now in while creating the CRUD object we also give the constructor the service’s degree: main.py # For leader:
crud = CRUDUser(service_info["leader"], service_info["degree"], followers)
# For follower:
crud = CRUDUser(service_info["leader"], service_info["degree"]) Consistency Hashing We already implemented consistency hashing in the caching article. This time we are doing in a slightly another way. The class method get_responsible_degrees will return the list with 2 degrees which will represent the partitions to which this data will be assigned. It computes the hash mod 360 of the index of the request and finds 2 nearest angles from 120, 240, and 360: @classmethod
def get_responsible_degrees(cls, string : str) -> list:
    '''
            This function finds the nearest responsible degrees for a string uuid.
        :param string: str
            The value for with to compute the hash and find the nearest deegrees.
        :return: list
            The list with the nearest degrees for the string uuid.
    '''
    angles_list = [120, 240, 360]
    # Computing the hash of the string.
    hash_str = hash(string)
    # Calculating the hash mod 360
    hash_mod_360 = hash_str % 360
    # Calculating the distance between hash mod 360 and all angles.
    dist_list = [abs(hash_mod_360 - angle) for angle in angles_list]
    # Find the nearest 2 angles with the lowest difference.
    responsible_indexes = sorted(range(len(dist_list)), key=dist_list.__getitem__)
    responsible_angles = [angles_list[responsible_indexes[index]] for index in range(2)]
    return responsible_angles This function is called in the get_selected_services which using the selected angles finds the services responsible for this request, being the leader itself or the followers. Yes, this hash function is computed only by leaders. This function is listed below: def get_selected_services(self, string : str) -> list:
    '''
        This function return the list of services responsible for the request.
    :param string: str
        The value which we use to compute the hash mode 360.
    :return: list
        The list of responsible services.
    '''
    selected_services = []
    # Getting the responsible angles.
    responsible_angles = self.get_responsible_degrees(string)

    # Adding itself if in responsible degrees is presented the deegree of the service.
    if self.deegree in responsible_angles:
        selected_services.append("me")
        responsible_angles.remove(self.deegree)
    # Adding the rest of responsible services.
    for angle in responsible_angles:
        for follower in self.followers:
            if follower["degree"] in responsible_angles:
                selected_services.append(follower)
    return selected_services Related to the CRUD functions, the only functions that are changing are the write ones, the create, update, and delete. The read functions also can be changed to use rerouting, however, we are going to create a gateway for this purpose in one of the future articles, so forwarding o requests will be used only for the write functions. Create While adding a record to the data store shard, if it’s a leader we first are computing the responsible services. Having these responsible services, we begin if checking if the service itself is responsible. If it is in the responsible services, then we add the record to the data store, then we are forwarding the request to another follower. If the leader isn’t one of the responsible ones then it is just forwarding the requests to the followers. If this code is run by a follower then it just skips all leader-related code and just adds the record to the data store. def create(self, user_dict : dict):
    '''
        This function adds the new user to the data store and forwards the request to other services if it's the leader.
    :param user_dict: dict
        The dictionary containing the user's information.
    :return: dict, integer
        The response and the status code of the request.
    '''
    resp_services = []
    # If the service is the leader then we are creating a new uuid for the record and getting the list of
    # responsible services.
    if self.leader:
        index = str(uuid.uuid4())
        user_dict["id"] = index
        resp_services = self.get_selected_services(index)
    if user_dict["id"] not in self.users:
        # Checking the conditions for adding the data to the data store.
        if (self.leader and "me" in resp_services) or not self.leader:
            self.users[user_dict["id"]] = user_dict
            # Removing the "me" from the responsible services list.
            if "me" in resp_services:
                resp_services.remove("me")

        # Forwarding the request to the responsible followers.
        if self.leader:
            for follower in resp_services:
                requests.post(f"http://{follower['host']}:{follower['port']}/user",
                              json = user_dict,
                              headers = {"Token" : "Leader"})

        return user_dict, 200
    else:
        # Returning the error response if the user already exists.
        return {
                   "message" : "Error: User already exists!"
               }, 400 A practically identical code is added for the update and delete functions too: Update and Delete def update_user(self, index : str, user_dict : dict):
    '''
        This function updates the user's information in the data store.
    :param index: str
        The index of user to update the information.
    :param user_dict: dict
        The dictionary with the new values for the fields to update.
    :return: dict, int
        The response and the status code of the request.
    '''
    resp_services = []
    if self.leader:
        # Getting the responsible followers.
        resp_services = self.get_selected_services(index)
    if index in self.users:
        # Checking the conditions for updating the data to the data store.
        if (self.leader and "me" in resp_services) or not self.leader:
            self.users[index].update(user_dict)
            # Removing the "me" from the responsible services list.
            if "me" in resp_services:
                resp_services.remove("me")
        # Forwarding the request to the responsible followers.
        if self.leader:
            for follower in resp_services:
                requests.put(f"http://{follower['host']}:{follower['port']}/user/{index}",
                             json = self.users[index],
                             headers = {"Token" : "Leader"})

        return self.users[index], 200
    else:
        # Returning the error response if the user already doesn't exist.
        return {
                   "message" : "Missing user!"
               }, 404

def delete_user(self, index : str):
    '''
        This function removes the user from the data store.
    :param index: str
        The index of the user to delete from the data store.
    :return: dict, int
        The response and the status code of the request.
    '''
    resp_services = []
    if self.leader:
        # Getting the responsible followers.
        resp_services = self.get_selected_services(index)
    if index in self.users:
        # Checking the conditions for updating the data to the data store.
        if (self.leader and "me" in resp_services) or not self.leader:
            user_dict = self.users.pop(index)
            # Removing the "me" from the responsible services list.
            if "me" in resp_services:
                resp_services.remove("me")
        # Forwarding the request to the responsible followers.
        if self.leader:
            for follower in resp_services:
                requests.delete(f"http://{follower['host']}:{follower['port']}/user/{index}",
                                headers = {"Token" : "Leader"})

        return user_dict, 200
    else:
        # Returning the error response if the user already doesn't exist.
        return {
                   "message" : "Missing user!"
               }, 404 At rest, the main.py, and module remains unchanged. Just ensure that you updated these modules in all services folders and run the application. crud.py To test it send a POST request to the leader. You will see that the requester has forwarded to at least one another service. If you will send a get request with the returned uuid to this service you will get the data about the user from another service. This means that the data was assigned to the partition shared by these two services. Conclusion Sharded services are a form of saving the amount of data stored in a distributed system ensuring at the same time the data consistency in case of multiple partitions per node. In this article we explored how to create a harder data store with multiple partitions per node, keeping in such a way instead of 3D, 2/3 D amount of data. In the next article, we are going to explore how to dynamically assign partition leaders and how to re-assign a new one when the previous leader was declared dead The full commented code of the class can be found here: GitHub URL

Understanding Partitioned Services in Distributed Systems 

121 Stories To Learn About Management And Leadership

The following central theme of the “Designing Data-Intensive application” by Martin Kleppmann is often Distributed Systems are built to handle high amounts of data. However at the same time to make this data highly available the data is stored at many services simultaneously, being it as replicas or as shared services. In this tutorial, we are going to implement replicated services for storing data which we will make a shared data store in the future. Problem formulation. In distributed stores, especially when we are having many replicas of the same store, we need to ensure high consistency in data. This means that we need to have the same information about an entity on each of the nodes in the cluster. It at first seems like a simple problem to solve, just make a copy of every data on all nodes. However, the problem comes when this data isn't static, meaning that it changes over time. This problem is illustrated below: Mike writes in the database the value 1 in all services (illustrated by W(1)), writing to all services, in the following order: Replica 1, Replica 2, and Replica 3. At the same time, Susan writes the value 2, but in another order: Replica 3, Replica 2, and Replica 1. As shown in the figure. They overwrite each other's writes in Replica 1 and Replica 3. And when they read their own reads they get other values than the ones they have written. In such a way the Data Store isn’t any more consistent. Leader and Followers. The most common solution to the problem described above is leader-based replication. In such data stores, each node has been named a replica. Each replica is either the Leader or the Follower. The Leader takes all write requests and distributes them to the followers, followers not being able to make writes, if they aren’t coming from the Leader. Leaders can process at the same time the writes and reads coming from the external world, while the Followers can process only reads from the external world and writes from the Leader. This mechanism ensures the consistency of the data in the system if the system is Partition Tolerant. The Leader Based replication is illustrated below: When Mike makes a write it sends a request to the Leader of the Cluster, performs the write, and forwards the change to the followers. When all writes are made the Leader returns the confirmation message. Then Mike can perform a read (and suppose his request where redirected to the F1). At this time Susan’s request wasn’t forwarded to the Followers so Mike gets back his value. Then when Susan makes her write, without messing with the Mike reads. Transaction Saga. Transaction saga is one of these spooky words that we have in distributed service. It actually means the process of executing sequentially multiple local transactions on multiple services. In our case when the Leader gets a write request and forwards this change to other services, it executes a transaction saga. Transaction saga is a pattern that has mainly two forms: Orchestrator. Choreography. Choreography Transaction sagas: Following the Microsoft documentation: Choreography is a way to coordinate sagas where participants exchange events without a centralized point of control. With choreography, each local transaction publishes domain events that trigger local transactions in other services. This pattern is illustrated below: Orchestrator Transaction sagas: In contrast to choreography, in this pattern, a centralized controller is needed. It tells the saga participant what local transactions to execute. Also in case of failures, it can ask services to execute compensating transactions to roll back the store. This pattern is illustrated below: In the example of the Distributed store, we are going to implement the Orchestrator form of the Transaction Saga, where the Orchestrator is the Leader of the replication cluster. Python implimentation. All nodes in our distributed data store will be a Flask service. Instead of using a database, we are going to use a dictionary for storing data. Each service will implement the CRUD functionality. These functionalities will be implemented in the . In this tutorial, we are going to configure manually the leader, in one of the following articles, I am going to show you how can Leader election be done. CRUDUser CRUDUser. CRUD functionalities are implemented in the separated library as the CRUDUser class. The class constructor takes the following arguments: leader (bool) - the binary value which decides if it behaves as a leader or follower. followers (dict, default = None) - the dictionary containing the information about followers, None in case of the followers. # Importing all needed modules.
import uuid
import requests


class CRUDUser:
    def __init__(self, leader : bool, followers : dict =None):
        '''
            The constructor of the CrudUser.
        :param leader: bool
            The parameter deciding if the service is a leader or not.
        :param followers: dict, default = None
            The dictionary containing the credentials of the services.
        '''
        self.users = {}
        self.leader = leader
        if self.leader:
            self.followers = followers The Create, Read, Update, and Delete functions are similar to the ones from the Service Discovery Article. However, of the Leader, it should forward the transaction to the followers and in case of create operation, it should also create a new UUID for the new entities. Bellow is illustrated each CRUD operation function: def create(self, user_dict : dict):
        '''
            The create function from CRUD, This function adds a service to the datstore.
        :param user_dict: dict
            The dictionary containing the information about users.
        :return: dict, int
        '   The response and the status code.
        '''
        # If the service is a leader the service adds the user to the data store.
        if self.leader:
            index = str(uuid.uuid4())
            user_dict["id"] = index
        if user_dict["id"] not in self.users:
            # If the service is a follower the service and the user is not registered
            # the user is added to the data store.
            self.users[user_dict["id"]] = user_dict

            # If the service is a leader then forwards the request to the followers.
            if self.leader:
                for follower in self.followers:
                    requests.post(f"http://{follower['host']}:{follower['port']}/user",
                                  json = user_dict,
                                  headers = {"Token" : "Leader"})

            # Returning the response.
            return user_dict, 200
        else:
            return {
                "message" : "Error: User already exists!"
            }, 400 As shown above, in the case of a leader a new UUID is created, and the value is added to the store. Then the entities, with the new UUID are forwarded to the followers. A key aspect for the leader to recognize the Leader’s request is the Leader adding a header token - “Leader” value, to be recognized by the follower, and perform the local transaction. In the case of Read functionally the process is a little simpler because the reads can be performed from any service the function just returns the requested value if they exist, if not a 404 error status code is added: def get_user(self, index : str):
        '''
            This function returns a user by the index from the data store..
        :param index: str
            The index of the requested user.
        :return: dict, int
        '   The response and the status code.
        '''
        # Return the user's information if it exists.
        if index in self.users:
            return self.users[index], 200
        else:
            # Return the error message if user doesn't exists.
            return {
                "message" : "Missing user!"
            }, 404

    def get_users(self, user_id_list : list):
        '''
            This function returns a list of users from the data store.
        :param user_id_list: list
            The list with user ids.
        :return: dict, int
        '   The response and the status code.
        '''
        # Fining the set of missing ids from the list.
        missing_ids = set(user_id_list).difference(list(self.users.keys()))

        # If there are missing ids then an error code is returned.
        if len(missing_ids) > 0:
            return {
                "message" : "Missing ids!",
                "ids" : list(missing_ids)
            }, 404
        else:
            # If all ids are present in the data store a list with user credentials are returned.
            user_info = {index : self.users[index] for index in user_id_list}
            return user_info, 200 The Updated and Delete functionalities, follows a similar operation as in the case of the Create. The transaction is done locally, then forwarded to the followers: def update_user(self, index : str, user_dict : dict):
        '''
            This function updates the user's information with the provided information.
        :param index: str
            The index of the user in the data store.
        :param user_dict: dict
            The new users information.
        :return: dict, int
        '   The response and the status code.
        '''
        # Checking if the user id is registered.
        if index in self.users:
            # Updating the user's information.
            self.users[index].update(user_dict)

            # If the service is the leader the it forward the information to the followers.
            if self.leader:
                for follower in self.followers:
                    requests.put(f"http://{follower['host']}:{follower['port']}/user/{index}",
                                 json = self.users[index],
                                 headers = {"Token" : "Leader"})

            # Returning the response and the status code.
            return self.users[index], 200
        else:
            return {
                "message" : "Missing user!"
            }, 404

    def delete_user(self, index : str):
        '''
            This function deletes a user from the data store by index.
        :param index: str
            The index of the user in the data store.
        :return: dict, int
        '   The response and the status code.
        '''
        # Checking if the user id is registered.
        if index in self.users:
            # Deleting the user from the data store..
            user_dict = self.users.pop(index)

            # If the service is the leader the it forward the request to the followers.
            if self.leader:
                for follower in self.followers:
                    requests.delete(f"https://{follower['host']}:{follower['port']}/user/{index}",
                                    headers = {"Token" : "Leader"})

            # Returning the response and the status code.
            return user_dict, 200
        else:
            return {
                "message" : "Missing user!"
            }, 404 Next, we are going to implement the service, First, we need to import the CRUDUser class and the Flask modules, configure the service, and create it: # Importing all needed modules.
from flask import Flask, request
from crud import CRUDUser


# Defining the service information.
service_info = {
    "host" : "127.0.0.1",
    "port" : 8000,
    "leader" : True
}

# Defining the followers information. (only presented in the leader).
followers = [
    {
        "host" : "127.0.0.1",
        "port" : 8001
    },
    {
        "host" : "127.0.0.1",
        "port" : 8002
    }
]

# Creating the data store.
crud = CRUDUser(service_info["leader"], followers)

# Creating the flask application.
app = Flask(__name__) During the write requests (Create, Update, and Delete), we check a special condition before making the write. For the write to happen one of the following conditions needs to happen: The service should be a leader. The Leader Token should be present in the request Headers. These conditions are verified in the following listing: if not crud.leader and ("Token" not in headers or headers["Token"] != "leader"):
		# Return error 403 Access denied!
    else:
		# Make the write. Below are the endpoints of the service. @app.route("/user", methods = ["POST"])
def add_user():
    '''
        This function handles the create requests.
    '''
    # Extracting the headers and checking if request can be processes.
    headers = dict(request.headers)
    if not crud.leader and ("Token" not in headers or headers["Token"] != "leader"):
        return {
            "message" : "Access denied!"
        }, 403
    else:
        # Trying to create a user in the data store.
        return_dict, status_code = crud.create(request.json)
        return return_dict, status_code


@app.route("/user", methods=["GET"])
def get_users():
    '''
        This function handles the read some requests.
    '''
    # Getting the users ids.
    user_list = request.json["users_id"]
    # Getting the response and status code from the tha data store.
    return_dict, status_code = crud.get_users(user_list)
    return return_dict, status_code


@app.route("/user/<index>", methods=["GET"])
def get_user(index):
    '''
        THis function handles the read one requests.
    '''
    # Getting the response and the status code from the data store.
    return_dict, status_code = crud.get_user(index)
    return return_dict, status_code


@app.route("/user/<index>", methods=["PUT"])
def update_user(index):
    '''
        This function handles the update requests.
    '''
    # Extracting the headers and checking if request can be processes.
    headers = dict(request.headers)
    if not crud.leader and ("Token" not in headers or headers["Token"] != "leader"):
        return {
            "message" : "Access denied!"
        }, 403
    else:
        # Getting the new credentials from the request.
        new_user_data = request.json
        # Trying to update the user's information and getting the response and status code from the data store.
        return_dict, status_code = crud.update_user(index, new_user_data)
        return return_dict, status_code


@app.route("/user/<index>", methods=["DELETE"])
def delete_user(index):
    '''
        This function handles the delete requests.
    '''
    # Extracting the headers and checking if request can be processes.
    headers = dict(request.headers)
    if not crud.leader and ("Token" not in headers or headers["Token"] != "leader"):
        return {
            "message" : "Access denied!"
        }, 403
    else:
        # Trying to delete the user and getting the response and status code from data store.
        return_dict, status_code = crud.delete_user(index)
        return return_dict, status_code Finally, we need to run our application: app.run(
    host = service_info["host"],
    port = service_info["port"]
) Now to finish the application you need to copy these two files in two additional folders, getting the following structure: But don't forget in service-2 and service-3 (which are going to be the followers to change the configurations: service_info = {
    "host" : "127.0.0.1",
    "port" : 8000,
    "leader" : True
}

followers = [
    {
        "host" : "127.0.0.1",
        "port" : 8001
    },
    {
        "host" : "127.0.0.1",
        "port" : 8002
    }
]
crud = CRUDUser(service_info["leader"], followers)
# Becomes.
service_info = {
    "host" : "127.0.0.1",
    "port" : 8001,
    "leader" : False
}

crud = CRUDUser(service_info["leader"])
# And
service_info = {
    "host" : "127.0.0.1",
    "port" : 8002,
    "leader" : False
}

crud = CRUDUser(service_info["leader"]) Now we can finally run the applications in three separate terminals. If you are going to make a written request to the Leader, it will be propagated to the followers too. However, making a similar request to followers will return a 403 error status response. However, read requests will work for all services, Leaders, and followers. Conclusion. Leader-Follower replication is a simple approach for creating distributed stores. It ensures data consistency and allows multiple users to access simultaneously data. However, because of the replication we are storing 3 copies of the data, which can be pretty expensive. In the following article, we are going to talk about partitioned or shared services, which are going to keep the consistency, but at the same time reduce by one-third the amount of the data stored. The full commented code of the class can be found here: GitHub URL Written by Păpăluță Vasile LinkedIn: Instagram: GitHub: https://www.linkedin.com/in/vasile-păpăluță/ https://www.instagram.com/science_kot/ https://github.com/ScienceKot

Distributed Data Store and Transaction Sagas

What kind of leadership do people need in challenging times when the atmosphere is far from calm? What do teams expect from their manager? There is no single answer here because everything depends on the nature of the crisis. Some practitioners argue that instead of vision per se, teammates need some kind of "holding," which is the ability to acknowledge people's emotions and give them a sense of context and reality against all odds. I believe that vision is always needed even during difficult stages, but perhaps not as far-seeing as usual. As the project progresses, there are goals and objectives and a certain distance that needs to be covered. But when, for instance, war comes to a country, your vision is blocked by the questions “Will there be work tomorrow?” or “Will there be tomorrow at all?”. In such a coordinate system, a vision has a small focal length, but it requires transparency and clarity. Fueling morale Under stress, a person's cognitive flexibility is reduced, which means the perception of information is somewhat distorted. We have to be mindful of what and how we tell our teammates and how we ourselves, as leaders, show our flexibility. The first thing I considered necessary was to convey to the employee that everything one does, matters a lot. Yes, we all found ourselves in a dire situation, but we share much more than that - we have a common passion. And if there are things that prevent us from doing it, our task is to help each other deal with everything that stands in our way. Plus, we all perfectly realize the truth: the client is not to blame for the fact that we have a crisis. Each of us is responsible for the success of the project. And the universal understanding of our duties and obligations does not allow everything to fall apart. Therefore, it needs constant replenishment. In our team, a persistent reminder of the importance of our work for the client and ourselves worked perfectly. At the same time, of course, there were cases when the internal resource dried up, and people communicated their fatigue. First of all, you need to give the teammate the opportunity to rest and only afterward analyze and discuss the causes of fatigue or burnout. When a person acknowledges their state and comes to the leader with this, in no case should one devalue a person’s feelings, saying: “Nah, come on, you are fine.” Let a colleague recuperate. Even when letting someone go on a two-week vacation, try to keep in touch delicately and find out whether rest helps or additional time is needed. After vacation comes to an end, you can tackle the root cause of the problem with renewed vigor. Imagine that you find yourself in an environment where your emotional state is being hit by external circumstances beyond your control. In addition, they do not stop and will surely surround us for some time. I, as a manager, do not think that here you can solve anything by talking the talk. The problems of people who experience hostilities are deep-seated; they need to be worked out with specialists. Emotions: calming the waters Since the end of February 2022, I have observed a whole range of feelings and emotions of my people. But most of all, I had to deal with fear, and this fear had many faces: fear due to a lack of understanding of what was happening, uncertainty about tomorrow, and sometimes even today. For the first six months, all people's questions boiled down to one thing: “what will happen next?”. I cannot say that today we know much more or are more certain. But, due to our nature and internal national settings, we are wired to get used to things and adapt. Of course, the team was quite rightly worried about how things would be with the work and whether everyone would be able to keep it. Now there are other questions about whether there is connection, electricity, or any communication. If there is no network either at home or in the office, what can be done to establish a working mode? The first month was the most difficult because the fear was primitive — people simply feared for their lives. And hand in hand with this feeling came a number of other emotions, including irritability. Nevertheless, all experiences motivated people to get in touch more often and join calls and meetings. We organized separate sessions where we just talked and shared our affairs and who felt what. The remote mode was supplemented by evacuation and resettlement; people were even more scattered across regions and countries. Everyone had their own story and their hardships, and everyone should definitely be heard. No one wanted to fight their own fight alone. Authentic Leadership and Transparency Of course, there are always things that shouldn't be said out loud or shared with the team. Let's say there is a team that works, and you, as a leader, need to save it. People do not need to know now that if this unity is not maintained, the client will leave. In such an environment, the focus should shift to the people themselves and the importance and timeliness of each of them. Here we are talking about balanced truth, that is, communicating the things which will not add even more stress. This leads us to the topic of communication with people. There is a difference between reporting a fact; let’s compare: “If your performance goes down, it will affect the team” and “if your performance goes down, everyone will be fired.” Same idea, but various wrapping. My approach now is that I have become more interested in the burning, pressing problems of each teammate. If, in normal times, such communication comes down to a brief conversation about the state of affairs, today, it is talking about security, the benefits of civilization, the presence of warmth, shelter, and essentials. Whether everyone has a place to go in case of a blackout. In general, transparent leadership is a must at all times; it is unlikely to change from external circumstances. This is also an internal attitude, which in turn is based on three pillars. First, a sense of balance. There are no perfect companies where the sun always shines; there are always cloudy days and storms. Here, too, you need to maintain a balance because sometimes the team reacts painfully to negative information, which affects the overall mood. So here, sometimes, the leader must show support for the team and, perhaps, even this vibe. At the same time, you will then be able to navigate all this energy in a certain direction. Second, honesty matters a big deal in terms of expectations from the employee. A person should have a clear idea of ​​what the company expects, and if the expectations are not met, then one has the right to honest feedback on this matter. And the third is consistency and commitment to yourself, your ideals, and your approaches. In fact, I think that in a crisis, a manager should not invent anything new or make dramatic changes. The main thing is to be true to yourself. Of course, an individual approach to everyone has a place to be, and it is mandatory. Another thing is that it should not radically differ from person to person or between teams. Whatever teams I worked with, I followed my established outline, adapting where necessary to the client, business, or any other stakeholder. But there is only one single vector reflecting how you choose to interact with the environment. Self-leadership, inspiration, and work on myself Now, I have no official mentors, although structurally, there are people I report to. I constantly watch my leaders; there are things I like and use in my team in the future. There are types of communication and leadership styles that are not close to my heart, and I will not practice them. I experiment a lot, test approaches, and see what works and what doesn't. For my self-development as a leader, in my opinion, the most important thing is to work with a growing number of people. In general, each person, except for yourself, is a new separate experience that you require. For each specific case, you find a code. I draw inspiration from my colleagues at work. One of these people is Andrii Poddubnyi, Software Development Director. I learned a lot from him, and I think it shows. There are many teams that respect him and drive inspiration from him, who have grown under his leadership and work consistently and effectively. I think his phenomenon is rooted in being brutally honest. People hear from him exactly the truth they need to hear. Thanks to him, I also learned about the reverse side of sole decision-making, felt all the pitfalls, drew conclusions, and built my culture. Taboo: something that is always beyond the pale There are things that I, by virtue of my business ethics, will never allow myself, and no circumstances will affect this. I can't imagine myself saying the phrase, "Your problems are not that serious." Now in our realities, there are no small or insignificant issues. You never know what is really hidden under this thick layer of emotions. I, as a leader, have no right to belittle the significance of everything human, either in thoughts or conversation. If a person completely trusts you and comes to share, this requires a reverent attitude. People are very good at feeling when they are not as important as they would like to be. In this article, Cheslav Novytskyi, an Engineering Manager at , describes how to lead an engineering team during challenging times. Innovecs

Stories, News & Mentions about SELF-LENDER

Self-lender’s Stories on HackerNoon

Self-lender's News & Mentions