When a Distributed Systems Class Becomes a Career Catalyst

Picture this: I'm sitting in my Distributed Systems exam, heart racing as I face a ten-mark question about Remote Procedure Calls. The question demands a diagram, and my mind scrambles to recall some bit of knownledge I heard about gRPC, Protocol Buffers, and bidirectional communication patterns for me to put something down. Despite my best efforts to sketch something coherent, I know my answer barely scratches the surface of what's required.

You know that feeling when you've missed the target even before seeing the results? Yeah, that was me in that moment.

Rather than brushing it off and moving on, the experience lit a fire under me. What exactly was an RPC? Why was it important in distributed systems? How does it differ from the REST APIs I'm comfortable with?

The more I researched, the more I discovered about software architectures I hadn't fully understood:Here are some of the findings:

: Software organized in horizontal layers, with each layer communicating only with adjacent ones.

: Kernel, drivers, system calls, applications

: Enables programs to call procedures on remote systems as if they were local.

: Google's high-performance RPC framework

: Remote method calls between Java objects

: Applications structured as loosely coupled services with standardized interfaces.

: Separate services for accounts, loans, investments

: Business modules integrated through service interfaces

: Small, independent services developed and deployed individually.

: Hundreds of services for recommendations, authentication, content

: Thousands of services for distinct business capabilities

: Systems where components communicate through events from producers to consumers.

: Market data events triggering analysis and trades

: Sensor events activating connected devices

No Theory Goes without a Practical Application Behind It :The Challenge

Learning without application is like reading about swimming without ever getting wet. I needed a real project to cement my understanding.

That's when it hit me – why not convert one of my most familiar integrations, the M-Pesa Daraja API, from REST to RPC?

: Google's high-performance RPC framework using Protocol Buffers

: End-to-end typesafe APIs made easy, built for TypeScript developers

After weighing the options, I chose tRPC. Why? Because who doesn't love the 

? The promise of type safety across frontend and backend was too good to pass up.

Move Fast and Break Nothing. End-to-end typesafe APIs ...

 : his is waht trpc means to every eveloper that adopts it....

For those not familiar, tRPC (TypeScript Remote Procedure Call) creates end-to-end typesafe APIs without schemas or code generation. Unlike traditional REST APIs where you need to manually maintain type definitions, tRPC leverages TypeScript's type inference to ensure full type safety across your client and server.

The key advantages that led me to choose tRPC for this integration:

: Full end-to-end type safety without any code generation

: Autocompletion and compiler checks catch errors before runtime

: No need for separate API documentation or validation libraries

: Handle authentication and token management with tRPC middleware.

: Build secure and efficient API calls using TypeScript.

: Implement clean and straightforward client-side logic.

: Discover the advantages of tRPC in reducing bugs and improving documentation.

Basic understanding of Mpesa-Daraja Api (Reference this article  && great should out to the author Mary Maina 

 requires a specific authentication flow:

It uses the username and password to obtain an accesstoken that u can progressively use in the other subsequent invocations.....

Obtain an access token from their authorization API

Use this token in subsequent API calls (STK Push, B2C, C2B, etc.)

In my original REST implementation, I used Express middleware to handle this authentication flow:

For reference i will be  using my own implementaion that i did back then 

The middleware would fetch the token and attach it to the request object, making it available to downstream handlers. But how would this work in the tRPC paradigm?

The frontend makes a request to initiate payment with a phone number and amount

The backend authenticates with the M-Pesa API

The server sends an STK Push request to M-Pesa

M-Pesa sends a payment prompt to the user's phone

The user confirms payment by entering their PIN

M-Pesa sends the result back to our callback URL

Before diving into implementation, it's important to understand the key differences:

HTTP-based with explicit routes and HTTP methods

Authentication typically handled through middleware

Request and response formats vary (JSON, form data, etc.)

Below is an illustration of the Rest Architecture pattern 

Middleware works differently than in Express

Dive into our programming articles for insights and tips. Covering a range of topics, they're perfect for learners at any level eager to expand their knowledge.

Dive into our programming articles for insights and tips.

Articles

MPesa Daraja 2.0 + TRPC 

Authentication is one of the ways of securing your applications (the communication between the client and server) and one effective method is 

, which ensures users can securely access protected resources

This guide explains how token authentication works, focusing on 

This is a method where users authenticate once and receive a token, which is then sent with every request to verify identity. Unlike session-based authentication, which relies on storing session data on the server, tokens allow for 

There are different kind of authentication methods, which are:

 - Single Sign-On via third parties like Google, Microsoft, etc.

 Hardware devices like YubiKeys, smart cards

 (email & password) on the client side, by filling in a form.

The client sends it to the server, which is then validated

 securely (e.g., in memory or HTTP-only cookies).

 in the request header for protected routes.

One of the widely used methods for securing API authentication. They provide a stateless way of authenticating users, allowing applications to verify identity without storing session data on the server.

 is a compact, URL-safe token format that encodes JSON objects to form a secure way in which data is transferred through two parties. It mainly consists of three parts:

 - Specifies token type and signing algorithm that is used.

 - Contains claims (usually data about the user or entity). like user ID, role, and expiration time.

 - Ensures token integrity using a secret key. A signature is created using the algorithm specified in the header to sign a combination of the encoded header, the encoded payload and a secret. The secret helps us verify that the token hasn’t been tampered with and should be kept somewhere safe (you can use env variables)

NOTE: You should not always include sensitive data in the payload, since it isn't secured by default unless there is additional encryption.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Authentication flow: in-depth explanation

Validate and sanitize input (e.g., check email format, ensure fields aren’t empty, enforce strong passwords).

Package the data into a JSON object and send it to the signup endpoint.

Hash and salt the password using a library like 

Check for duplicate users (if needed) and save the user details in the database.

NB: Enhance the authentication flow by redirecting users directly to the app after signup instead of the login page. Since we already have the user’s credentials, we can issue an access token upon signup, just like during login.

Collect user credentials and validate input (e.g., check email format, ensure fields aren’t empty).

Package the data into a JSON object and send it to the login endpoint.

Compare the stored hashed password with the one provided by the user.

Using a JWT library, generate two tokens:

Short-lived (expires in minutes or hours).

Contains essential data like user ID, roles, and permissions.

Used to generate new access tokens when the current one expires.

Sent back to the client as a JSON response.

Stored in memory using state, context, or variables (e.g., in React).

Used in the Authorization header for all protected requests.

NB: Avoid storing access tokens in local storage due to XSS risks. Keeping them in memory is safer unless the application has JavaScript injection vulnerabilities.

Automatically included in requests to the server.

Helps mitigate XSS attacks and, with proper security settings, can prevent CSRF attacks.

NB: Configuring SameSite cookies or CSRF tokens can further enhance your security.

 is primarily used for authenticating requests. It is short-lived, typically lasting from a few minutes to several hours. With every request, the access token is sent in the 

 to verify the user's identity and permissions. Since it expires quickly, it has a lower security risk. Access tokens generally contain data such as the 

 is used to generate new access tokens when the current one expires. It has a much longer lifespan, lasting from 

 dedicated to refreshing tokens. Unlike access tokens, refresh tokens are typically stored in an 

 for added security. They contain minimal information, such as the 

, but pose a higher security risk if exposed, as they can be used to obtain new access tokens.

The client includes the access token in the Authorization header of each request.

The server verifies the token, checks its expiry, decodes it, validates permissions, and then processes the request.

When the access token expires, the client requests a new one using the refresh token.

The server retrieves the refresh token from the HTTP-only cookie, verifies it, and issues a new access token.

Optionally, the old refresh token can be blacklisted to prevent reuse.

The client stores the new access token and continues making requests.

NB: Passport.js provides a robust authentication library that simplifies this process across various frameworks.

 Detects token expiry errors on the client, requests a new token, and retry the failed request automatically—seamlessly handling it in the background.

 Track token expiry on the client and refresh it before it expires. However, this method may introduce unnecessary requests, impacting performance.

This approach ensures a smooth user experience without requiring users to manually re-authenticate frequently.

Below are some of the practices in points you can consider:

 to encrypt traffic and prevent token interception. 

 and avoid hardcoding them in the codebase. 

 by scope and role-based access control (RBAC)

This guide gives you a heads-up for how token-based authentication works and makes it easy to understand while implementing it in any of your favorite languages.

Token-Based Authentication Guide

Amazon Simple Storage Service (S3) is a foundational offering in cloud computing, designed to store and retrieve any amount of data from anywhere on the web. Known for its scalability, durability, and reliability, AWS S3 powers countless applications—from website hosting and big data analytics to backup and disaster recovery. Its pay-as-you-go model ensures flexibility, making it a preferred choice for businesses of all sizes.

However, as data accumulates over time, managing storage costs and ensuring efficient utilization can become challenging. Factors such as storing infrequently accessed data in high-cost tiers or retaining outdated files can inflate expenses unnecessarily. Additionally, manually managing data transitions across storage classes can be tedious and error-prone.

This is where AWS S3 lifecycle policies come into play. By automating data transitions between storage classes and setting expiration timelines, lifecycle policies empower users to streamline storage management. These policies not only help reduce costs but also ensure compliance with data retention requirements, all while minimizing manual intervention.

AWS S3 lifecycle policies are a set of rules that automate the management of object storage over time. Designed to optimize storage costs and simplify data retention processes, these policies enable users to control how objects are stored, transitioned, or deleted based on their age or other defined criteria.

With lifecycle policies, you can define rules that:

Transition objects between S3 storage classes (e.g., from S3 Standard to S3 Glacier) based on their usage patterns.

Delete objects that are no longer needed after a specified duration.

Clean up incomplete multipart uploads to avoid unnecessary costs.

 By automatically moving infrequently accessed or archival data to cost-effective storage classes, lifecycle policies minimize unnecessary expenses.

 Policies can be configured to retain data for a specific duration to meet regulatory or business requirements, ensuring seamless adherence to governance policies.

 Lifecycle rules eliminate the need for manual intervention, allowing users to focus on strategic tasks rather than operational overhead.

In summary, S3 lifecycle policies are a robust and flexible tool for managing the full lifecycle of your data, from frequent access in high-performance tiers to long-term storage in low-cost archival classes.

AWS S3 offers a variety of storage classes, each tailored to different access patterns, durability requirements, and cost considerations. Lifecycle rules allow you to transition objects between these storage classes automatically, optimizing costs based on how frequently data is accessed.

High durability, low latency, and high throughput.

Ideal for active datasets such as web applications, content distribution, or data processing.

Automatically optimizes costs by moving objects between access tiers based on access patterns.

No operational overhead, charges a monitoring fee per object.

Suitable for datasets with unpredictable or changing access patterns.

For data that is accessed less frequently but requires rapid access when needed.

Lower storage cost than S3 Standard with slightly higher retrieval costs.

Backups, disaster recovery, or long-term data storage with occasional access.

Similar to Standard-IA but stored in a single availability zone.

Lower cost than Standard-IA but less resilient to data loss.

Non-critical or reproducible data that can tolerate availability zone loss.

Archive storage with millisecond retrieval.

Low-cost storage for rarely accessed data requiring instant access.

Medical records or regulatory documents requiring quick retrieval.

Low-cost archive storage with flexible retrieval options (minutes to hours).

Lower storage costs with options for expedited, standard, or bulk retrievals.

Archives or data backups with infrequent access needs.

The lowest-cost storage option for long-term archiving.

Retrieval times range from 12–48 hours.

Data rarely accessed, such as compliance archives or historical records.

Relationship Between Lifecycle Rules and Storage Classes

Lifecycle rules act as a bridge between S3 storage classes, enabling automated transitions based on data age or custom criteria like object tags. For example:

 after 30 days of no access to save costs.

 after a year for long-term, low-cost storage.

Expire or delete data after its retention period ends.

These rules ensure your data is stored in the most cost-efficient class throughout its lifecycle, with minimal manual intervention.

Example Use Case: Transitioning Infrequently Accessed Data to Glacier Classes

Consider a scenario where you have log files generated daily, stored in an S3 bucket:

 for the first 30 days to allow frequent access for analysis.

 to reduce costs while maintaining quick access.

 after 180 days for long-term, low-cost storage.

Expire the logs entirely after 365 days to comply with data retention policies.

By defining these lifecycle rules, you can optimize storage costs while ensuring the availability of critical data at each stage of its lifecycle.

Lifecycle policies in AWS S3 are built using rules that define how and when objects are transitioned between storage classes or deleted. These rules ensure data is stored efficiently, aligning with your cost and accessibility requirements.

 Filters objects based on their key name. For instance, a prefix of 

 applies the rule to all objects under the 

Applies rules to objects with specific metadata tags. For example, you can tag objects with 

 Define when objects are moved to a different storage class. For example, transition objects to S3 Glacier after 90 days.

Specify when objects should be permanently deleted. For instance, delete objects 365 days after creation.

Steps AWS Follows When Evaluating Lifecycle Rules

Each rule is checked against object metadata, including creation date, tags, and prefix.

If an object meets the criteria, AWS applies the defined transition or expiration action.

Example: Transitioning Data After 30 Days of Creation

Scenario: You store transactional logs in S3 and want to reduce costs as they age.

Result: Your logs are stored cost-effectively throughout their lifecycle without manual intervention.

 Daily server logs are generated and accessed for the first month for analysis.

 - Significant cost savings while maintaining compliance with log retention policies.

 Application backups need long-term storage for disaster recovery.

 Reliable, low-cost backup storage with compliance to data retention requirements.

 Your data access patterns are unpredictable.

, which automatically moves objects between access tiers based on usage.

 You achieve optimal storage costs without having to predict or manage access patterns.

Learning S3 Lifecycle Policies for the AWS SAA exam

Elastic Load Balancers (ELB) are a core AWS service that automatically distributes incoming traffic across multiple targets, such as EC2 instances, containers, or IP addresses, within one or more availability zones. They enhance fault tolerance and ensure high availability for your applications.

Among the three types of ELBs—Application Load Balancers (ALBs), Network Load Balancers (NLBs), and Gateway Load Balancers (GWLBs)—the ALB is designed for Layer 7 (application layer) routing. This means ALBs understand application-level protocols like HTTP and HTTPS, making them ideal for web applications and APIs.

Choosing an ALB is particularly advantageous when:

 to direct traffic to specific backends based on domain names (e.g., 

microservices or containerized applications

 where dynamic, fine-grained request routing is crucial.

For the AWS Certified Solutions Architect – Associate (SAA) exam, understanding ALBs is essential, as they often appear in scenarios related to designing scalable and secure web architectures.

An Application Load Balancer (ALB) is a managed service that acts as a Layer 7 load balancer, providing advanced traffic distribution and intelligent request routing for modern web applications.

Improve the availability and fault tolerance of your application.

Route user requests to the appropriate backend resources based on defined rules.

ALBs are particularly useful for applications with complex routing needs, such as microservices or multi-tenant architectures.

ALBs evaluate incoming requests and route them based on various factors like HTTP headers, request paths, or hostnames. This flexibility supports use cases like path-based routing (

 to another) and host-based routing (e.g., routing traffic for 

ALBs integrate seamlessly with ECS, EKS, and Kubernetes clusters, enabling dynamic load balancing for containerized workloads. You can register individual containers as targets, ensuring efficient traffic distribution even in rapidly scaling environments.

Search For

MPesa Daraja 2.0 + TRPC

Token-Based Authentication Guide

Learning S3 Lifecycle Policies for the AWS SAA exam

Mastering Application Load Balancers for the AWS SAA Exam

Mastering AWS Security Groups for the AWS SAA exam

Machine Learning Services for the AWS SAA-C03 Exam

Real-Time Data Processing with Amazon Kinesis

Understanding Disaster Recovery in AWS for the AWS SAA exam

The Best Way to Add External Scripts to Your Vue App

Practice Frontend, Android and iOS by building real world projects.