DEV Community: Kennedy Njoroge

Autoscaling doesn't save you at 30,000 requests per second — your dependencies do

Kennedy Njoroge — Mon, 05 Oct 2026 09:57:01 +0000

There's a comfortable story about peak traffic: load goes up, the autoscaler notices, pods multiply, everyone keeps their evening. I've watched that story hold, and I've watched it fail in a specific and instructive way — the autoscaler worked perfectly and the platform degraded anyway.

Running transaction paths at sustained peaks in the tens of thousands of requests per second teaches you that horizontal scaling is the easy half of the problem. The hard half is that everything your new pods talk to did not scale, and now there are more of them asking.

The failure that taught me this

Scale-up triggers. Pods go from 12 to 40 in about ninety seconds. Each one opens its configured pool of 20 database connections on startup.

The database's connection limit is 500.

Twelve pods needed 240 connections and everything was fine. Forty pods want 800. The database starts refusing connections, the pods that can't connect fail their readiness probes, the orchestrator restarts them, they try to connect again, and you have built a very efficient machine for denying yourself service. The autoscaler, meanwhile, sees rising latency and scales up further.

The dashboards looked bizarre: CPU low, memory low, replica count healthy, error rate vertical.

Autoscaling converts a capacity problem into a concurrency problem on whatever you depend on. If that dependency is a fixed-size resource — a connection limit, a license seat count, a rate-limited upstream, a legacy system with a thread pool — scaling out makes things worse, not better, and it does so fast.

Budget connections globally, not per pod

The fix is to stop thinking about per-pod configuration and start thinking about a global budget:

pool_size_per_pod × max_replicas ≤ dependency_limit × safety_factor

With a 500-connection database, 0.8 safety factor (leave headroom for migrations, admin sessions, the other service nobody told you about), and a 40-replica ceiling:

pool_size ≤ (500 × 0.8) / 40 = 10

Then pin both halves so neither drifts:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 12
  maxReplicas: 40          # ← this is a dependency constraint, not a cost one
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_inflight_requests
        target:
          type: AverageValue
          averageValue: "35"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 600

Three things worth calling out.

maxReplicas is load-bearing. Document why it's 40, next to the number, or someone will raise it during an incident to "give it more capacity" and cause the exact outage they're trying to stop.

Scale on in-flight requests, not CPU. A service waiting on a slow downstream has low CPU and is in serious trouble. In-flight count — or queue depth — tracks saturation. CPU tracks work, and at peak the problem is usually waiting, not working.

Asymmetric windows. Scale up fast, scale down slowly. Flapping replicas means constantly re-establishing connections, which is precisely the pressure you're trying to avoid.

Retry budgets, or how three services become twenty-seven

Service A calls B calls C. Each retries three times on failure, which is the default in a lot of client libraries and sounds reasonable in isolation.

C has a bad minute. B's single call becomes 3. A's single call becomes 9. Your users' single click becomes 27 requests to a service that is already struggling. Retries turn a brownout into an outage, reliably, and the blame lands on whoever's service fell over last rather than whoever configured the retries.

Two rules that have held up for me:

Retry at one layer only. Usually the outermost one that can still do something useful. Everything beneath it fails fast and propagates.

Cap retries as a fraction of total traffic, not per request. This is what service meshes mean by a retry budget — "retries may not exceed 20% of requests to this destination". Under normal conditions nobody notices. Under failure, the budget exhausts and retries simply stop, which is exactly the behaviour you want and exactly the behaviour per-request configuration cannot express.

Pair it with a circuit breaker so that a hard-down dependency fails in microseconds instead of consuming a connection for a 30-second timeout:

outlierDetection:
  consecutive5xxErrors: 5
  interval: 10s
  baseEjectionTime: 30s
  maxEjectionPercent: 50

maxEjectionPercent: 50 is the detail people skip. Without it, a bad deploy or a network partition can get every endpoint ejected and you've turned a partial failure into a total one.

The failover you haven't run is not a failover

Every platform I've worked on had a documented DR procedure. The useful question is never whether it exists, it's: when did a human last execute it, and how long did it take?

If the answer is "during the audit, and about forty minutes", you don't have failover. You have a document. Forty minutes of manual steps under pressure is where people typo a hostname into a production config.

Making it real means making it a script, and making the script run on a normal Tuesday:

#!/usr/bin/env bash
set -euo pipefail

TARGET_SITE="${1:?usage: failover.sh <dr|primary>}"

# 1. verify the target is actually healthy before sending traffic to it
./healthcheck.sh "$TARGET_SITE" || { echo "target unhealthy, aborting"; exit 1; }

# 2. pre-warm — a cold site that receives 100% of peak traffic will fall over
ansible-playbook -i "inventory/${TARGET_SITE}" scale-up.yml \
  --extra-vars "target_replicas=${PEAK_REPLICAS}"
./wait-for-ready.sh "$TARGET_SITE" --timeout 180

# 3. shift traffic in steps, checking error rate between each
for weight in 10 25 50 100; do
  ./set-traffic-weight.sh "$TARGET_SITE" "$weight"
  sleep 30
  ./assert-error-rate-below.sh 0.01 || { ./set-traffic-weight.sh "$TARGET_SITE" 0; exit 1; }
done

The pre-warm step is the one most often missing. Shifting full peak traffic onto a site running at minimum replicas gives you a cold start, an empty cache, and a thundering herd against the database, all at once — and the resulting outage gets attributed to the failover rather than to the lack of pre-warm.

The traffic ramp matters for the same reason: it gives you a cheap, reversible answer to "is the DR site actually serving correctly" before you're fully committed.

Telemetry that triggers things, not just dashboards

Most observability setups stop at displaying. The step after that is letting signals drive action — scale-up, pre-warm, failover — with clear, bounded authority.

What I'd automate, in order of how confidently I'd do it:

Scale-up on saturation. Safe, reversible, happens constantly.
Pre-warm the DR site on sustained primary degradation. Also safe — you're just spending some compute on standby capacity. Do this well before you'd consider failing over.
Traffic shift. Automate the steps, gate the decision on a human, at least until you've watched it work a dozen times. Automated failover with a flaky health signal gives you a system that fails over and back repeatedly, which is worse than either site being down.

And whatever you automate, the signal needs to be multi-source. A single probe failing is a probe problem until something else agrees with it. Requiring agreement between an error-rate signal and a synthetic transaction before acting cuts false positives dramatically, at the cost of a little latency on genuine failures. That's a good trade for anything that moves traffic between sites.

What to check this week

If peak is coming and you've got an afternoon:

Multiply your pool size by max replicas. Compare that number against every fixed-limit dependency. Do it for database connections, and then do it again for anything with a rate limit.
Trace a request through your stack and count the retry layers. If it's more than one, fix that before peak.
Ask when the failover was last executed by a human. If it's more than six months, schedule a rehearsal rather than a review.
Check what your HPA actually scales on. If it's CPU, ask what happens when the service is slow but idle.

None of this is exotic. It's just the half of scaling that doesn't show up in the autoscaler's dashboard, which is why it's the half that's usually missing.

Writing up what I learn about reliability, backend systems and data infrastructure. If you've had an autoscaler make an outage worse, I'd like to hear how.

A cache key ate 99.9% of my records and the pipeline looked green

Kennedy Njoroge — Mon, 05 Oct 2026 09:53:33 +0000

The worst pipeline bug I've shipped didn't throw. No stack trace, no failed job, no alert. Every run went green, finished inside its window, and wrote roughly one record out of every thousand it was handed.

The job's own metrics said it was healthy, because the job's own metrics counted runs, not rows. It took a business user asking why a campaign list looked short to surface it.

This post is about that class of bug — the pipeline that succeeds at doing nothing — and the three habits that make it structurally impossible rather than merely unlikely.

How you lose 99.9% of your data without noticing

Simplified, the stage looked like this. Records arrive in batches, get enriched against a reference lookup, and are staged before reconciliation downstream.

// the bug, reduced
String cacheKey = record.getAccountId();
Enrichment e = cache.get(cacheKey);
if (e == null) {
    e = lookupService.fetch(record);
    cache.put(cacheKey, e);
}
stage(record, e);

Spot it? accountId isn't unique per record. One account generates many records per batch — different products, different billing cycles, different dates. The key collapsed thousands of distinct records onto a handful of cache entries, and the downstream staging write was keyed off the same value. Last write wins. Everything else evaporated.

The job processed every record. It just persisted almost none of them.

The fix is one line, and the one line is not the lesson:

String cacheKey = String.join("|",
    record.getAccountId(),
    record.getProductCode(),
    record.getBillingCycle(),
    record.getRecordDate().toString());

The lesson is that nothing in the system was capable of noticing. That's the actual defect.

Habit 1: count rows at every boundary, and assert on the ratio

A pipeline stage should know how many records it received and how many it emitted, and should refuse to call itself successful when those numbers disagree in a way nobody authorised.

@dataclass
class StageResult:
    stage: str
    received: int
    emitted: int
    rejected: int
    reason_counts: dict[str, int]

    def assert_sane(self, min_ratio: float = 0.95) -> None:
        if self.received == 0:
            return
        accounted = self.emitted + self.rejected
        if accounted != self.received:
            raise PipelineError(
                f"{self.stage}: {self.received - accounted} records vanished"
            )
        if self.emitted / self.received < min_ratio:
            raise PipelineError(
                f"{self.stage}: emitted {self.emitted}/{self.received} "
                f"({self.emitted / self.received:.1%}) — below floor. "
                f"rejections: {self.reason_counts}"
            )

Two distinct checks doing different jobs. The first is conservation: every record either came out or was explicitly rejected with a reason. A record that is neither emitted nor rejected has vanished, and vanishing is always a bug. The second is a ratio floor: even when everything is accounted for, a sudden collapse in throughput means something upstream changed.

Deliberate filtering goes through rejected with a reason. That way "we dropped 40% because they were test accounts" is visible and intentional, and "we dropped 40% because of a cache key" is a hard failure.

I now treat a stage without row-conservation accounting as untested, regardless of how many unit tests it has. My own cache-key bug passed its unit tests, because the test fixture had one record per account.

Habit 2: make reruns boring

The question that separates a pipeline you can operate from one you can't: what happens if I run yesterday's batch again, right now?

If the answer involves checking anything first, the pipeline is fragile, because reruns are not an edge case. Reruns happen after an outage, after a bad upstream file, after a bug fix, and always under time pressure with someone asking when it'll be done.

Idempotency isn't a property you bolt on. It comes from one decision: every record has a deterministic natural key, and writes are keyed on it.

INSERT INTO staging_campaign_records (
    record_key, account_id, product_code, billing_cycle,
    record_date, amount, loaded_at, batch_id
)
VALUES (:record_key, :account_id, :product_code, :billing_cycle,
        :record_date, :amount, SYSTIMESTAMP, :batch_id)
ON CONFLICT (record_key) DO UPDATE SET
    amount    = EXCLUDED.amount,
    loaded_at = EXCLUDED.loaded_at,
    batch_id  = EXCLUDED.batch_id;

The record key is derived from the business meaning of the row — the combination of fields that genuinely identifies it — never from a sequence, a load timestamp, or a UUID generated at read time. Those are all "different every run", which is the opposite of what you need.

Then, crucially, a unique constraint on record_key in the database. Not a check in application code. Application checks race; a unique index is a promise the storage engine keeps even when two workers process overlapping batches.

Note what this gives you beyond safety: deleting and reloading a day's data becomes a thing you can do at 2 p.m. on a Tuesday without ceremony. That changes how fast you can fix things.

Habit 3: let history be history (SCD Type 2 without tears)

The other silent corruption is overwriting a dimension in place. Customer changes segment; you UPDATE the row; every report that ever referenced the old segment is now retroactively wrong, including the ones already circulated.

Type 2 slowly changing dimensions solve this by never updating a fact, only closing it:

-- close the current row when the tracked attributes actually changed
UPDATE dim_customer
   SET valid_to    = :effective_from - INTERVAL '1 day',
       is_current  = FALSE
 WHERE customer_id = :customer_id
   AND is_current  = TRUE
   AND (segment, tariff_plan, status)
       IS DISTINCT FROM (:segment, :tariff_plan, :status);

-- open a new one
INSERT INTO dim_customer (
    customer_id, segment, tariff_plan, status,
    valid_from, valid_to, is_current
)
SELECT :customer_id, :segment, :tariff_plan, :status,
       :effective_from, DATE '9999-12-31', TRUE
 WHERE NOT EXISTS (
       SELECT 1 FROM dim_customer
        WHERE customer_id = :customer_id
          AND is_current  = TRUE
 );

IS DISTINCT FROM is doing real work there — it's null-safe, so a genuine NULL → 'value' transition is detected rather than silently skipped the way != would skip it. And the WHERE NOT EXISTS on the insert makes the pair idempotent: run it twice with the same input and you get one version, not two.

Then querying as-of any point in time is trivial, which is the whole point:

SELECT f.*, d.segment
  FROM fact_usage f
  JOIN dim_customer d
    ON d.customer_id = f.customer_id
   AND f.usage_date BETWEEN d.valid_from AND d.valid_to;

Reports stop changing their answers about the past. Disputes become checkable.

The check that would have caught me

Row conservation, as a single assertion, at every stage boundary. That's it. The cache-key bug would have failed its very first run with emitted 1,204/1,100,000 (0.1%) — below floor, instead of looking healthy for weeks.

Everything else in this post is about making that assertion safe to act on: if reruns are idempotent, failing a batch loudly costs you nothing, so you can afford to fail loudly on anything suspicious. A pipeline that can't be safely rerun is a pipeline under pressure to keep going when it shouldn't — and that pressure is where silent data loss actually comes from.

Count what goes in and what comes out. A record that is neither emitted nor rejected has vanished.
Make reruns boring. Deterministic natural keys, upserts, unique constraints in the database.
Never overwrite history. Close the old row, open a new one.

None of it is clever. That's rather the point — clever is what ate my records.

More on backend systems, pipelines and reliability as I go. If you've got a favourite silent-failure story, I'd genuinely like to read it.

The boring part of an AI agent is the part that works

Kennedy Njoroge — Mon, 05 Oct 2026 09:52:14 +0000

Most of the time an incident spends "being worked on" isn't work. It's waiting to reach someone who can act on it. An alert fires, an email lands in a shared inbox, somebody skims it, guesses which team owns it, forwards it, and that team decides it isn't theirs. On a bad night that loop costs you an hour before anyone has opened a terminal.

I built an agent to collapse that loop for a BSS platform, and it took mean time to resolution on routed incidents from around two hours to about ten minutes. What surprised me is how little of that came from the language model. The model does one small job in the middle. Everything that makes the system trustworthy is plumbing.

This post is about the plumbing.

The shape of the problem

Incoming incident email is semi-structured in the worst way: there's a template, three systems ignore it, two append their own stack traces, and the one that matters most sends plain prose from a human. Regex gets you maybe 60% of the way and then rots every time an upstream team edits their alert body.

That 40% tail is exactly where an LLM earns its place. But "classify this email" is not the system. The system is:

poll inbox → normalise → classify → resolve owner → create ticket → notify → observe

The model is step three. Steps one, two, four, five, six and seven decide whether anyone trusts it.

Normalise before you classify

The single highest-leverage thing I did was aggressively strip the email before the model ever saw it. Signatures, legal footers, quoted reply chains, base64 inline images, and the forty lines of Received: headers are pure token cost and pure distraction.

import re
from email import policy
from email.parser import BytesParser

QUOTE_MARKERS = (
    "-----Original Message-----",
    "From:",
    "On ... wrote:",
)

def extract_body(raw: bytes) -> str:
    msg = BytesParser(policy=policy.default).parsebytes(raw)
    part = msg.get_body(preferencelist=("plain", "html"))
    text = part.get_content() if part else ""

    # cut the reply chain at the first quote marker
    for marker in QUOTE_MARKERS:
        idx = text.find(marker)
        if idx > 0:
            text = text[:idx]

    text = re.sub(r"\n{3,}", "\n\n", text)
    return text.strip()[:4000]

That [:4000] matters. Truncation is a feature. An incident email that needs more than 4000 characters of context to classify is one a human should be reading anyway.

Make the model return a shape, not a sentence

The classification call is deliberately small and deliberately constrained. I ask for structured output with a fixed enum of teams, a confidence score, and a one-line rationale.

from pydantic import BaseModel, Field
from typing import Literal

Team = Literal[
    "billing", "provisioning", "network", "identity",
    "integrations", "data-platform", "unknown",
]

class Triage(BaseModel):
    team: Team
    severity: Literal["sev1", "sev2", "sev3", "sev4"]
    confidence: float = Field(ge=0.0, le=1.0)
    rationale: str = Field(max_length=200)

Three details that are easy to skip and expensive to skip:

unknown is a valid answer. If the enum has no escape hatch, the model will pick the nearest plausible team and sound certain about it. Giving it somewhere honest to go is the cheapest accuracy win available.

The rationale is capped. Not because anyone reads it in the happy path, but because when triage goes wrong at 3 a.m. the rationale is the only artefact that tells you whether the model misread the email or the owner map was stale. A 200-character cap keeps it a signal rather than an essay.

Confidence is the model's, and it's directional at best. Treat it as a tiebreaker, not a probability. I threshold it, but the threshold is tuned against observed outcomes, not against what the number claims to mean.

The owner map is not the model's problem

Here's the part that no amount of prompting fixes: the model can tell you a ticket is about billing. It cannot know that billing's on-call rotated yesterday, or that the billing team split into two squads last quarter.

So the model resolves to a team, never to a person. A separate lookup against the directory — in my case Microsoft Graph — resolves the team to whoever is actually on call right now.

async def resolve_owner(team: str, graph) -> Owner:
    group = OWNER_GROUPS[team]            # static, version-controlled mapping
    members = await graph.group_members(group)
    on_call = await graph.on_call_for(group)   # calendar-driven
    return on_call or members[0]

This split is what makes the thing survive org changes. When a team reorganises, somebody edits a YAML file. Nobody retrains anything, nobody rewrites a prompt. The LLM's view of the world is "what is this email about", which is stable. The volatile knowledge lives in systems that are already the source of truth for it.

If you take one thing from this post: never let the model hold facts that another system owns.

Route low confidence to a human, loudly

async def handle(mail: Mail) -> None:
    body = extract_body(mail.raw)
    triage = await classify(body)

    if triage.team == "unknown" or triage.confidence < 0.72:
        await post_to_triage_channel(mail, triage, reason="low_confidence")
        return

    owner = await resolve_owner(triage.team, graph)
    ticket = await create_ticket(mail, triage, owner)
    await notify(owner, ticket, triage)

The fallback is not a failure path, it's the default path for anything ambiguous, and it lands somewhere visible. Early on, roughly one in six emails went to the human channel. That felt like a bad number until I looked at what was in it: most were genuinely ambiguous, and the ones that weren't told me exactly which alert template to fix upstream. The fallback queue is your best source of improvement work.

Idempotency, because email is not a queue

Mail APIs will hand you the same message twice. Your poller will crash between "created ticket" and "marked as read". Somebody will replay a batch to test something.

Every message gets a deterministic key, and ticket creation is conditional on it:

def dedupe_key(mail: Mail) -> str:
    # message-id is stable across redelivery; subject+sender is the fallback
    raw = mail.message_id or f"{mail.sender}|{mail.subject}|{mail.sent_at}"
    return hashlib.sha256(raw.encode()).hexdigest()

Then a unique index on that key in whatever store backs you. Not a cache — a unique index. A cache will happily evict the thing under memory pressure and you'll find out when duplicate tickets land during your busiest hour. I have opinions about cache keys and silent data loss that I'll save for another post.

What I'd measure from day one

I started with "did it classify correctly", which turns out to be the least useful metric, because you can only compute it by hand on a sample.

What actually drove decisions:

Reroute rate — tickets reassigned within 30 minutes of creation. This is your real accuracy signal and it's free, because humans generate it just by doing their jobs.
Fallback rate — share going to the human channel. Trending up means an upstream alert format changed.
Time to first human action — the number the whole project exists to move. Not time to resolution; you don't control that.
Cost per message — unglamorous, but it's what lets you argue for the system's continued existence.

Reroute rate is the one I'd instrument first in any triage system. It's ground truth that costs nothing to collect.

The honest summary

The model is a classifier with good manners about unstructured text. That's genuinely useful and regex could not have done it. But the two-hour-to-ten-minute number came from: removing a human hop, resolving on-call automatically, and making the ambiguous cases land somewhere visible instead of somewhere polite.

If you're building something similar, budget your time accordingly. The prompt will take an afternoon. The owner map, the idempotency, the fallback path and the metrics will take the rest of the month, and they're the reason it still works six months later.

I write about backend engineering, data pipelines and reliability. If you've built something in this space and solved the owner-mapping problem differently, I'd like to hear it.

Interoperability: The Key to Unlocking Blockchain's Full Potential

Kennedy Njoroge — Tue, 14 May 2024 13:55:43 +0000

Introduction

Blockchain technology is rapidly evolving and has spawned many independent networks. Each network has its own unique advantages, but their isolation has prevented them from exchanging data and assets seamlessly across platforms. Interoperability, on the other hand, is a revolutionary trend that seeks to bridge these networks and foster collaboration, creating unprecedented opportunities.

What is Interoperability?

Interoperability in blockchain world is when different blockchains can communicate and share information in a seamless manner. This can include token exchange, smart contract data exchange, or even the creation of entire decentralized applications.

Why is interoperability important?

1.Enhanced Liquidity: Interoperability enables assets to move freely between blockchains, boosting liquidity and expanding market opportunities.

2. Scalability:Interoperability can alleviate congestion on individual blockchains by distributing the workload across multiple networks.

3.Increased Utilization: DApps can take advantage of the functionalities of multiple blockchains, creating new use cases and enhancing the user experience.

4.Collaboration: Projects can collaborate more effectively, combining their strengths to create innovative solutions.

Interoperability in Action: Cosmos Network

One of the most prominent examples of interoperability is the Cosmos Network, which uses the IBC protocol to securely and efficiently communicate between interconnected blockchains.Here is an example:

JavaScript
// IBC Module (Simplified)
class IBCModule {
  constructor(sourceChain, destinationChain) {
    this.sourceChain = sourceChain;
    this.destinationChain = destinationChain;
  }

  createPacket(data) {
    return {
      sourceChain: this.sourceChain,
      destinationChain: this.destinationChain,
      sequence: generateUniqueSequence(), // In reality, this would be managed meticulously
      timeoutHeight: getCurrentBlockHeight() + 100, // Timeout if not processed by dest. chain
      data: data,
    };
  }

  sendPacket(packet) {
    // 1. Sign the packet (omitted for simplicity, but crucial for security)
    // 2. Relay the packet to the source chain's IBC module
    //    This involves complex network communication, often via 'relayer' nodes
    sourceChain.ibcModule.submitPacket(packet); 
  }

  receivePacket(packet) {
    // 1. Verify packet authenticity, signatures, etc.
    // 2. Process the data based on its type
    switch (packet.data.type) {
      case 'tokenTransfer':
        processTokenTransfer(packet.data);
        break;
      // ... other data types
    }
  }
}

// Usage Example
const cosmosHubIBC = new IBCModule('Cosmos Hub', 'Osmosis');
const transferData = {
  type: 'tokenTransfer',
  amount: '100 ATOM',
  recipientAddress: 'osmo1...' // Osmosis address
};

const ibcPacket = cosmosHubIBC.createPacket(transferData);
cosmosHubIBC.sendPacket(ibcPacket);

In this simplified example, an IBC packet is used to transfer 100 ATOM tokens from the Cosmos Hub to the Osmosis blockchain.

Challenges and Future Viewpoint

Whereas interoperability holds monstrous guarantee, challenges still persist. These incorporate:

Governance: Establishing fair and transparent governance models for interconnected blockchains is a complex task.

Standardization: Developing standardized protocols and frameworks is crucial for widespread adoption.

Security: Ensuring secure cross-chain communication is paramount to prevent vulnerabilities and exploits.

Despite these challenges, the future of blockchain interoperability is bright. As the technology matures, we can expect to see:

Cross-chain DeFi: Decentralized finance applications that operate across multiple blockchains, offering users more diverse options.
Interconnected Metaverse: Virtual worlds that seamlessly connect with one another, enabling the transfer of digital assets and identities.
Universal Blockchain Identity: A single, self-sovereign identity that can be used across all blockchain platforms.

Conclusion

Interoperability is a game-changer for the blockchain industry. By enabling seamless communication and collaboration between networks, it unlocks a wealth of new possibilities for innovation and growth. As we move towards a more interconnected future, interoperability will play a pivotal role in shaping the next generation of blockchain applications and services.