Home Archives Search Feed

gRPC

Source: https://grpc.io/docs/what-is-grpc/introduction/

In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services. As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. On the server side, the server implements this interface and runs a gRPC server to handle client calls. On the client side, the client has a stub (referred to as just a client in some languages) that provides the same methods as the server.

gRPC is commonly used for service-to-service communication.

GRPC should be a replacement of your REST API and other synchronous forms of communication be it from a client (grpc-web) or backend-to-backend communication (just grpc).

In a sufficiently complex application you’ll always find the need for asynchronous communication for myriad reason, the most common likely being “holy shit we have to make 100 API calls when this action happens so we can notify everyone and their mom someone signed in”. This is where you’d use mqtt or pub-sub or kafka to publish a message/event and then let the people who care about that event manage subscribing to said event. This lifts the complexity burden of notifying everyone through API calls and replaces it with 20 lines of code to “publish user sign up event” and keeps your user sign up application/code lightweight and not dependent on all those downstream services being up and ready to receive an API call.

uid: 202211261243 tags: #distributed-systems

February 22, 2023

202211241007 The benefits of keeping a done list

Source: https://www.oliverburkeman.com/donelist  

This is why I’m such an enthusiastic proponent of keeping a “done list”, which starts empty, first thing in the morning, and which you then gradually fill with whatever you accomplish through the day. Each entry is a cheering reminder that you could, after all, have spent the day doing nothing constructive — yet look what you did instead! (If you’re in a serious psychological rut, just lower the bar for what gets to count as an accomplishment: nobody else need ever know that you added “brushed teeth” or “made coffee” to the list.)   But a done list isn’t merely a way to feel better about yourself. If you can give up the impossible quest to pay off your productivity debt, and instead start thinking of each day as an opportunity to move a small-but-meaningful set of items over to your done list, you’ll find yourself making better choices about what to focus on. And you’ll make more progress on them, too, because you’ll waste less time and energy being distracted by stress about all the other stuff you’re (unavoidably) neglecting.

This is pretty similar to Chris Krycho’s idea of an “Outcomes” header in your daily notes, with “Summary” and “Artifacts” subheaders. I’ve been using this for the last few days in my personal notes 202211230801 and it’s been great. I’ve not only been more encouraged to write, I’ve also been more encouraged to do things.

From Drafts

uid: 202211241007 tags: #drafts #productivity #task-management

February 22, 2023

Zookeeper As A Service For Shard Assignments

How zookeeper could be used in a shard assignment like service, allowing the “application to automatically recover from faults without human intervention”:

Another example arises when you have some partitioned resource (database, message streams, file storage, distributed actor system, etc.) and need to decide which partition to assign to which node. As new nodes join the cluster, some of the partitions need to be moved from existing nodes to the new nodes in order to rebalance the load. As nodes are removed or fail, other nodes need to take over the failed nodes’ work. These kinds of tasks can be achieved by judicious use of atomic operations, ephemeral nodes 202211232312, and notifications in ZooKeeper. If done correctly, this approach allows the application to automatically recover from faults without human intervention. It’s not easy, despite the appearance of libraries such as Apache Curator that have sprung up to provide higher-level tools on top of the ZooKeeper client API—but it is still much better than attempting to implement the necessary consensus algorithms from scratch, which has a poor success record.

Created from: Zookeeper 202211232246

uid: 202211232309 tags: #distributed-systems

February 22, 2023

Atomic Commits

How to do atomic commits? Two-phase commit.

Two-phase commit

Two-phase commit has a single coordinator and multiple participants.

First phase:

  • The coordinator sends a prepare request to each of the nodes, asking them whether they are able to commit.
  • If all participants reply yes, the coordinator sends a commit request in phase 2 (writing this on disk), and the commit takes place.
    • If the commit request fails or times out, the coordinator must retry forever until it succeeds.
  • If any of the participants replies no, then the coordinator sends an abort request.

Problems with 2PC: If the coordinator fails after it has sent out prepare requests to everyone, the participants are kind of stuck — they can’t abort anymore, because they must wait to hear back from the coordinator whether the transaction was committed or aborted.

Created from: Raft & Paxos 202211231100

uid: 202211232128 tags: #distributed-systems #software-engineering

February 22, 2023

Token Bucket

Similar to the Leaky Bucket 202211231056. Also used to check that data (packet) transmissions conform to defined limits on bandwidth and burstiness.

It can also be used as a scheduling algorithm to determine the timing of transmissions that will comply with the limits set for the bandwidth and burstiness.

The difference between the token bucket and the leaky bucket 202211231056 is that the output of the token bucket can be bursty.

Algorithm

  1. A token is added to the bucket once every 1/r seconds.
  2. The bucket can hold a maximum of b tokens. Nothing happens once you try to add a token to the bucket once it already has b tokens.
  3. If a packet of n bytes tries to enter the network:
    • If there are >= n tokens available in the bucket, let the packet through and decrease the number of tokens in the bucket by n.
      • If there are < n tokens, don’t remove any tokens, and the packet is considered non-conformant.

Non-conformant packets can be treated in various ways:

  • They may be dropped.
  • They may be enqueued for subsequent transmission when sufficient tokens have accumulated in the bucket.
  • They may be transmitted, but marked as being non-conformant, possibly to be dropped subsequently if the network is overloaded.

Created from: Algorithms to know before system design interviews 202211231052

uid: 202211231057 tags: #algorithms #software-engineering

February 22, 2023

Algorithms to know before system design interviews

  1. Geohash 202211231053 — Location-based service
  2. Quadtree 202211231054 — Location-based service
  3. Consistent hashing 202211231055 — Balance the load within a cluster of services
  4. Leaky bucket 202211231056 — Rate limiter
  5. Token bucket 202211231057 — Rate limiter
  6. Trie 202211231058 — Search autocomplete
  7. Rsync 202211231059 — File transfers
  8. Raft & Paxos 202211231100 — Consensus algorithms
  9. Bloomfilter 202211231101 Eliminate costly lookups
  10. Merkle tree 202211231102 — Identify inconsistencies between nodes
  11. HyperLogLog 202211231103 — Count unique values fast
  12. Count-min sketch 202211231104 — Estimate frequencies of items
  13. Hierarchical timing wheels 202211231105 — Job scheduler
  14. Operational transformation 202211231106 — Collaborative editing

uid: 202211231052 tags: #algorithms #software-engineering #interviews

February 22, 2023