2026-02-19 19:00:05
\ Rethinking latency-sensitive DynamoDB apps for multicloud, multiregion deployment
The entire process of delivering an ad occurs within 200 to 300 milliseconds. Our database lookups must complete in single-digit milliseconds. With billions of transactions daily, the database has to be fast, scalable, and reliable. If it goes down, our ad-serving infrastructure ceases to function.”
– Todd Coleman, technical co-founder and chief architect at Yieldmo
Yieldmo’s online advertising business depends on processing hundreds of billions of daily ad requests with subsecond latency responses. The company’s services initially depended on DynamoDB, which the team valued for simplicity and stability. However, DynamoDB costs were becoming unsustainable at scale and the team needed multicloud flexibility as Yieldmo expanded to new regions. An infrastructure choice was threatening to become a business constraint.
In a recent talk at Monster SCALE Summit, Todd Coleman, Yieldmo’s technical co-founder and chief architect, shared the technical challenges the company faced and why the team ultimately moved forward with ScyllaDB’s DynamoDB-compatible API.
You can watch his complete talk below or keep reading for a recap.
https://youtu.be/sk0mIiaOwM8?embedable=true
Yieldmo is an online advertising platform that connects publishers and advertisers in real time as a page loads. Nearly every ad request triggers a database query that retrieves machine learning insights and device-identity information. These queries enable its ad servers to:
The entire ad pipeline completes in a mere 200 to 300 milliseconds, with most of that time consumed by partners evaluating and placing bids. More specifically:
When a user visits a website, an ad request is sent to Yieldmo.
Yieldmo’s platform analyzes the request.
It solicits potential ads from its partners.
It conducts an auction to determine the winning bid.
The database lookup must happen before any calls to partners. And these lookups must complete with single-digit millisecond latencies. Coleman explained, “With billions of transactions daily, the database has to be fast, scalable and reliable. If it goes down, our ad-serving infrastructure ceases to function.”
Yieldmo’s production infrastructure runs on AWS, so DynamoDB was a logical choice as the team built their app. DynamoDB proved simple and reliable, but two significant challenges emerged.
First, DynamoDB was becoming increasingly expensive as the business scaled. Second, the company wanted the option to run ad servers on cloud providers beyond AWS.
Coleman shared, “In some regions, for example, the US East Coast, AWS and GCP [Google Cloud Platform] data centers are close enough that latency is minimal. There, it’s no problem to hit our DynamoDB database from an ad server running in GCP. However, when we attempted to launch a GCP-based ad-serving cluster in Amsterdam while accessing DynamoDB in Dublin, the latency was far too high. We quickly realized that if we wanted true multicloud flexibility, we needed a database that could be deployed anywhere.”
Yieldmo’s team started exploring DynamoDB alternatives that would suit their extremely read-heavy database workloads. Their write operations fall into two categories:
Given this balance of high-frequency reads and structured writes, they were looking for a database that could handle large-scale, low-latency access while efficiently managing concurrent updates without degradation in performance.
The team first considered staying with DynamoDB and adding a caching layer. However, they found that caching couldn’t fix the geographic latency issue and cache misses would be even slower with this option.
They also explored Aerospike, which offered speed and cross-cloud support. However, they learned that Aerospike’s in-memory indexing would have required a prohibitively large and expensive cluster to handle Yieldmo’s large number of small data objects. Additionally, migrating to Aerospike would have required extensive and time-consuming code changes.
Then they discovered ScyllaDB, which also provided speed and cross-cloud support, but with a DynamoDB-compatible API (Alternator) and lower costs.
Coleman shared, “ScyllaDB supported cross-cloud deployments, required a manageable number of servers and offered competitive costs. Best of all, its API was DynamoDB-compatible, meaning we could migrate with minimal code changes. In fact, a single engineer implemented the necessary modifications in just a few days.”
To start evaluating how ScyllaDB worked in their environment, the team migrated a subset of ad servers in a single region. This involved migrating multiple terabytes while keeping real-time updates. Process-wise, they had ScyllaDB’s Spark-based migration tool copy historical data, paused ML batch jobs and leveraged their Kafka architecture to replay recent writes into ScyllaDB. Moving a single DynamoDB table with ~28 billion objects (~3.3 TB) took about 10 hours.
The next step was to migrate all data across five AWS regions. This phase took about two weeks. After evaluating the performance, Yieldmo promoted ScyllaDB to primary status and eventually stopped writing to DynamoDB in most regions.
Reflecting on the migration almost a year later, Coleman summed up, “The biggest benefit is multicloud flexibility, but even without that, the migration was worthwhile. Database costs were cut roughly in half compared with DynamoDB, even with reserved-capacity pricing, and we saw modest latency improvements. ScyllaDB has proven reliable: Their team monitors our clusters, alerts us to issues and advises on scaling. Ongoing maintenance overhead is comparable to DynamoDB, but with greater independence and substantial cost savings.”
2026-02-19 18:50:13
\ Every morning, I open Gmail, planning to check messages quickly. Then my brain gets overwhelmed with long email threads, promotions, and updates. Over a cup of coffee, my important emails like “Scheduled VPS maintenance on 2026-02-10 07:00 UTC“ get buried, and 35 minutes disappeared quickly. I even missed the 9:30 am scrum meeting! Over time, this daily habit drained my focus and energy.
My email summary workflow is a lifesaver! It is technically an AI automation workflow, which is a part of business process automation.
I just needed to install n8n (it’s easy!), create a flow using an AI agent, and I get a clear summary. I see only what matters to me.
In this guide, you will learn how an AI-powered Gmail Summary Agent helped me save around 35 minutes a day.
\
AI automation means using software to handle repetitive tasks automatically. I do not even need to skim my inbox; the email summary arrives to a different low traffic email id. And my phone dings. While my coffee gets prepared.
For me, this means less time on routine tasks and more time for growth. AI Automation workflow frees you; it does not replace you. Many workflows still need a human in the loop – especially social media post generators!
\
n8n is an AI Automation workflow tool that connects apps without heavy coding. It uses visual blocks called nodes to build automation. My first node was an AI Agent node that uses Groq, a free AI model provider. It was very easy to build – even a child can drag and drop nodes, right?
I love hosting the n8n instance on my own server in Bangalore – thus ensuring that client data stays in-house and within the country. The self-hosted version is free for developers and very affordable if you already have a server to spare.
\
AI agents are like personal assistants that never sleep, need coffee or bathroom breaks. They are always ready and happy to help! In email workflows, they read messages, think, analyse and create summaries.
Instead of hundreds of emails, you receive one clear report organized by categories (You will see the cool output later). Feel free to tweak the workflow to your liking!
\
Last week, I missed an SBI Credit Card Statement – it got lost in the noise. Last month, I missed an important email from my kids’ school – their admission procedures. Luckily, I was able to find it before the due date after my dad reminded me of it! See the problem?
Ding! The ping of a new email breaks my chain of thought. It’s very disturbing. So, my notifications are now off for Gmail. It’s easy to make blunders when distracted.
Before I ran the AI automation workflow, I was too busy to check my mail often. Many emails slipped through.
\
The Gmail Summary Agent is an n8n AI automation workflow that runs automatically at a set time every day.
It gets unread emails for the past 24 hours, removes spam and promotional mail, analyses content using an OpenAI node, creates a category-wise summary and sends it to an email id of your choice. The summary also highlights action items under the “Actions to Take” section.
You receive one summary instead of many emails. Once set up, the system works daily with no manual effort.
Here is the complete workflow, ready to import into n8n. Give it a try on your local PC or server and let me know!
\
This Gmail Summary Agent follows a set process. Each step plays an important role in making the automation reliable. Note that the workflow is completely customizable.
The Schedule Trigger node starts the workflow at a fixed time every day. For example, 9:00 AM. This ensures you receive your summary before starting your work.
\
The Gmail node connects to Gmail using the given credentials and collects unread emails from the past 24 hours. I used a search filter for this: newer_than:1d
Most n8n node windows contain 3 sections:
1. Input from the previous node
2. Current node configuration
3. Output of the current node
\
Unwanted emails, such as ads and newsletters, are removed. This improves summary quality and reduces noise. I used a Filter node to exclude emails that have the label: CATEGORY_PROMOTIONS
\
Next, an Aggregate node is used to extract important details like id, From, To, snippet, Subject, threadId into a single list. These fields are useful for later nodes.
The output becomes an array of JSON objects that is sent to the AI node as one item for easy processing:
\
[
{
"data": [
{
"id": "19c460ca793167da",
"threadId": "19c460ca793167da",
"snippet": "A brief summary since...",
"From": "HCL GUVI Forum <[email protected]>",
"To": "[email protected]",
"Subject": "[HCL GUVI Forum] Summary"
}
]
}
]
\
\
Using the “Message a Model” action of the OpenAI node, the AI agent reads the email snippets. It groups them by type. It creates short summaries. It collects the email subjects and thread IDs for that type. It finds tasks that need action.
You need to decide which AI model provider and model to use. I used OpenAI’s gpt-5-mini model here. Create OpenAI credentials before configuring this node.
You will need a User Prompt to give directions to the AI model for what it needs to do.
Here’s the full prompt.
The prompt also contains the JSON schema to guide the AI model to produce proper JSON output for further steps.
Important JSON keys
“type” – Category of this set of mails.
“paragraph” – A summary of the set of mails that fall under the above category
“links” – Email Subject and Thread ID, which will be used by downstream nodes to generate links to that specific mail.
\
The Code node (JavaScript) is used to convert the AI output into well-styled Category and Action HTML cards. This makes the report easy to read and understand.
Here’s the full code.
\
Using the “Send a Message” action of the Gmail node, the well-formatted HTML summary is sent to your inbox. You receive one clear summary with everything you need.
\ This complete process forms an AI automation workflow that runs daily without supervision.
The Message area contains HTML code that forms the core structure and styling of the summary email. Feel free to modify it according to your liking.
Here’s the HTML code.
In the code, these blocks contain n8n expressions (JavaScript) that reference the output (cards) from the previous Code node:
\
<div class="cards">
{{ $json.typeBlocksHtml }}
</div>
<div class="section-title">Actions to Take</div>
<div class="actions-container">
{{ $json.actionsListHtml }}
</div>
\
The email summary is in HTML format and is arranged cleanly in the form of category-wise cards. Below the category cards are the “Actions to take” cards.
Here’s an example from my inbox:
\
Once emails are collected and filtered, the AI model starts its work. It reads each message carefully, like how a human would scan emails and decide what matters most.
The AI model groups related emails together. For example, Server monitoring alerts from UptimeRobot and Datadog may go into one category card, at the top.
The most important category cards are added at the top. Thus, the order of high priority is from top to bottom. Investment updates go into another category card, just below monitoring.
Security Alerts form a separate category card. This includes emails from Google Cloud regarding security best practices and a public interest notification from ICICI Bank, warning me of digital arrest scams.
After grouping, the AI model creates a short summary paragraph. This paragraph explains the main points from multiple emails in each category card in a concise way.
The AI model also looks for action items. If an email asks for approval, feedback, or a reply, it highlights that task. This helps you avoid missing important responsibilities.
Once the AI automation workflow is set up, the entire thing runs in the background. No manual steps needed.
\
You do not need to log into any dashboard - The summary arrives like a normal Gmail or Outlook message. Or Yahoo, if you prefer that.
I set the AI automation workflow to send the summary to another low-volume inbox so that I get one ‘ding’ in the morning, and that’s it. Great.
The email includes clickable links. Need more details? You may open the original email thread with one click. This saves time compared to searching manually in Gmail.
(Links only work on PC, Mac or Linux. Not on phones for now.)
\
One of the biggest pros of using a Gmail Summary Agent is time savings.
“The average professional spends around 2.5 hours per day reading and answering email, which is roughly 25–30% of their working time.” - Readless
With this n8n AI automation workflow, the colourful category cards attract my attention. 5 to 10 minutes is all it takes to skim through the summary, but pause and digest the most important points.
“AI‑powered email automation can cut 50–60% of the time spent on email‑related tasks, often saving several hours per week for heavy email users.” – Artsmart Blog
For those who manage clients, teams, and partners, the time saved gives them a major edge over their competitors.
\
Saving time is nice, but what really got me excited? Well-built AI automation workflows! And the build process itself. It’s so satisfying to see them run without bugs and deliver results every time.
First, it boosts response speed. When important emails are highlighted, you reply faster. This strengthens client relationships and builds trust.
Second, it tightens task management. Action items are clearly listed. You no longer rely on memory. Nothing important slips through the cracks.
Third, it enhances decision-making. When information is organized and summarized, you see patterns. You understand priorities better. You make smarter choices.
Fourth, it reduces stress. A clean inbox reduces anxiety. You feel more in control of your workload. This leads to better focus and long-term productivity.
Finally, it supports scalability. As your business grows, email volume increases. Automation allows you to handle more work without burning out.
\
An IT company founder works differently, compared to a clothing chain founder. That is why customization is a key strength of this workflow. You can adapt the AI automation workflow to match your business needs.
Some prefer daily summaries. Others want two summaries per day. You can add multiple rules to the Schedule Trigger node in n8n to achieve this. I tried adding one at 9 am and another at 6 pm and it works!
You can mark important clients, investors, or partners as priority contacts. I could mark my company as important using the system prompt of the OpenAI node. Emails from these senders will be highlighted in the summary.
The AI agent follows prompts. You can change these instructions to make summaries shorter, longer, or more formal. This improves accuracy and relevance.
The AI Agent can be connected to a wide variety of tools. For example, action items can be sent directly to Trello, Notion, or Slack. For this, just replace the “Message a model” node with an AI Agent node and connect a model and tools to it.
For growing companies, the system can be expanded for teams. Each department can receive its own summary. This is an interesting AI automation workflow use case that I have yet to pursue.
\
Microsoft states Copilot in Outlook can scan an email thread and create a summary, showing email workflows are being augmented with AI capabilities that go beyond traditional rules/filters. - Microsoft Copilot in Outlook
With Gemini in Gmail, you can: Summarize an email thread. Suggest responses to an email thread. Draft an email. Find information from previous emails. Find information from your Google Drive files. Get information about Google Calendar events. Create events in Google Calendar. – Google, Gmail Help
Gartner predicts that by 2028, more than 20% of digital workplace applications will use AI-driven personalization algorithms to generate adaptive experiences, supporting the idea that workplace tools (including communication apps like email) will become more personalized over the next few years. - Gartner
Market tracking indicates rapid growth in “AI-powered email assistant” products, with one market report projecting growth from $1.74B (2024) to $2.11B (2025), consistent with an evolving, expanding category. – Research and Markets
Advanced AI automation workflows will become a standard in modern businesses, just like accounting or CRM software is today.
\
Managing emails does not have to be stressful. With the right workflow, your inbox can become well organized – also check out Jono Catliff’s Email Inbox Manager, which I also set up on my n8n instance. But it will check for new emails every minute, so reduce the scheduler’s frequency if you are concerned about API costs!
It is an AI automation workflow that uses an AI Text Classifier node to segregate emails by adding labels according to their content. It then identifies emails that need a reply and drafts a reply in the same thread (for you to review). It saves time. It reduces mental fatigue. It improves decision-making.
For busy professionals, this is more than convenience. It is a strategic advantage. It allows you to use that time to be more productive. Develop new strategies. Take on new challenges. Lead teams. Change the world, maybe?
2026-02-19 18:25:26
Beyond being a cliché, "artificial intelligence" and its associated automation technologies have driven major developments in security, signifying that important changes have occurred in this field. In the field of cybersecurity, artificial intelligence refers to systems that acquire data, trace patterns, and forecast trends. Typically, this application is performed using machine learning, neural networks, or other high-performance data processing algorithms. There are limited domains in which an AI-driven system is more effective than humans or conventional security systems, such as detecting security threats, connecting unrelated incidents across various geographical or logistical contexts, and examining large datasets for subtle attack indicators that are often missed by humans or conventional security systems.
While traditional automation is constrained to predefined instructions, intelligent automation leverages artificial intelligence through playbooks and reasoning processes. This enables systems to analyze the outcomes they receive, make suitable decisions, or perform a series of predetermined tasks beyond simple ‘if-then’ rules. A simple example is a system that detects a malicious device and, if appropriate, isolates the bad actors by isolating the device. Such devices can suggest removing the malicious endpoint from the network or implementing a specific set of controls without the manual approval of security personnel.
AI, in combination with intelligent automation, plays a significant role in changing the operation of security functions. To ensure security, system architectures must incorporate preventive measures that shift security responsiveness toward flexible prediction and continuous defense strategies. This method improves how organizations identify, manage, and address security concerns, thereby promoting a more proactive security strategy.
\
Modern security teams face several key challenges:
When automated attacks are considered, the speed and scale of the offence even exceed those of the best security teams. Thus, an AI and automation framework that can help in detecting and responding to such attacks at all times within the suggested time is deemed necessary.
\
Frameworks such as Security Orchestration, Automation, and Response (SOAR), User and Entity Behavior Analytics (UEBA), and Zero Trust are important for addressing current security challenges, as noted in the previous section. When SOAR is operational, response times improve, crime decreases, and rapid actions are taken without requiring physical intervention. UEBA employs AI to analyze user behaviour to detect deviations from normal patterns, such as internal threats or stolen credentials. With Zero Trust, each individual and device is authenticated continuously, regardless of location, ensuring that only authorised access is granted.
It should be noted that the power of AI-based threat intelligence is sufficient to provide discerning attention to emerging threats, thereby enabling their prevention. Security teams can rely on AI to manage vulnerability scanning, enabling them to identify risks and remediate them promptly, thereby reducing the attack surface.
Here's a simple Python example for automating incident response with SOAR integration:
import requests
import os
API_TOKEN = os.getenv("API_TOKEN")
BASE_URL = os.getenv("API_URL")
# Example function to isolate a compromised endpoint
def isolate_endpoint(endpoint_ip):
url = f"{BASE_URL}/isolate"
payload = {"ip": endpoint_ip}
headers = {
"Authorization": f"Bearer {API_TOKEN}",
"Content-Type": "application/json"
}
response = requests.post(url, data=payload, headers=headers)
if response.status_code == 200:
print(f"Endpoint {endpoint_ip} isolated successfully.")
else:
print("Failed to isolate endpoint.")
# Trigger isolation for an identified compromised system
# isolate_endpoint(ip_address)
This framework simplifies and accelerates security operations, enabling faster responses to threats.
\
Here are practical, real‑world ways that AI and intelligent automation are being used today:
Machine learning-powered systems examine extensive log data to identify diverse behaviours on multiple endpoints, such as the reactions of different victims when subjected to particular network events. Some of these algorithms employ hierarchical learning rather than signature‑based methods and examine how certain activities change and evolve.
For instance, User and Entity Behavior Analytics uses machine learning to identify normal activity patterns and to detect anomalies and abnormal behavior by employees or third parties. Alerts from such Work are based solely on differences when the deviation confidence is in milliseconds.
SOAR platforms are designed to integrate additional tools, such as AI, that can receive observations and act on them, rather than requiring analyst intervention. For example:
This reduces the Mean Time to Respond (MTTR) and mitigates the incident without exacerbating it.
One reason AI is fundamentally distinct is that it helps you understand vulnerability data, the probability of certain attacks, and how they occur. Instead of focusing on adjusting the basic Common Vulnerability Scoring System, the analysis focuses on the risk contributed by the estimated vulnerabilities. Machines can conduct patch-lift and patch-shift campaigns and apply configuration changes in accordance with pre‑approved policies.
Cloud environments are a source of large volumes of data. AI identifies compliance statuses, network traffic, user behaviors, and indirect invasions, all of which occur in real time, assesses associated risks, and prevents configurations from directly resulting in breaches. AI‑driven aspect administrators and authentication ensure prospective cyber-attack prevention by employing zero-trust best practices: they identify suspicious network activity in real time and issue a multifactor authentication request.
Today, advanced email filtering is powered by artificial intelligence. Various systems utilize sentiment analysis, email sender statistics, read-on ratios, email click rates, and other factors to provide such protection, enabling them to outperform even static rule-based content filters vastly.
\
AI has powerful capabilities; however, its effectiveness is enhanced by human participation in governance processes and in interpreting critical risk issues. One strategy used in a human-in-the-loop (HITL) setup is widely practised in domains where human operators control and assist AI systems, with the level of risk determining the degree of human involvement. Hence, in such arrangements, AI is used to support rather than replace decision-making in critical situations.
Here, AI is responsible for routine tasks, such as pattern recognition and process automation, thereby increasing productivity. Conversely, people assume greater responsibilities, such as making moral or ethical judgments and understanding the relevant context. This makes such consolidation possible without time loss and is unbreakable because the system is centralized.
These actions help strengthen AI systems and improve security responses.
Here is a Python code snippet that shows how AI and human oversight can work together to automate security-centric activities and make better decisions in terms of security
import requests
import pandas as pd
from sklearn.ensemble import IsolationForest
import logging
import os
API_TOKEN = os.getenv("SOAR_API_TOKEN")
API_BASE_URL = os.getenv("BASE_API_URL")
# Example: Adversarial testing for model vulnerabilities
def test_adversarial_model(model, test_data):
adversarial_data = generate_adversarial_data(test_data)
predictions = model.predict(adversarial_data)
if any(pred == -1 for pred in predictions): # Checking for misclassifications
print("Adversarial vulnerability detected!")
else:
print("Model is secure.")
def generate_adversarial_data(data):
# Scafolding function for generating adversarial data (to be implemented)
return data
# Example: Automating data retraining pipeline
def retrain_model(model, data):
model.fit(data)
print("Model retrained with new data.")
# Example: Automated anomaly detection with Isolation Forest
def detect_anomalies(data):
model = IsolationForest()
model.fit(data)
predictions = model.predict(data)
anomalies = data[predictions == -1]
if len(anomalies) > 0:
print(f"Anomalous behavior detected: {anomalies}")
return True
return False
# Example: Automating response action (disconnecting device)
def automated_response(action, ip_address):
if action == "disconnect":
# Example API request to disconnect a device
url = f"{API_BASE_URL}/disconnect"
payload = {"ip": ip_address}
response = requests.post(url, data=payload)
if response.status_code == 200:
print(f"Device {ip_address} disconnected successfully.")
else:
print(f"Failed to disconnect device {ip_address}.")
# Example: Logging AI decision for transparency
def log_decision(action, details):
logging.basicConfig(filename='ai_decisions.log', level=logging.INFO)
logging.info(f"Action: {action}, Details: {details}")
# Example: Automating threat intelligence gathering
def gather_threat_intelligence():
response = requests.get(API_BASE_URLh)
threat_data = response.json()
# Process and update security systems based on new threat data
print("Threat intelligence gathered:", threat_data)
# Main execution
data = pd.DataFrame({'login_time': [8, 9, 10, 16, 17, 3]}) # Sample data for anomaly detection
model = IsolationForest()
# 1. Adversarial testin
test_adversarial_model(model, data)
# 2. Data retraining
retrain_model(model, data)
# 3. Anomaly detection
if detect_anomalies(data):
# 4. Automate response action if an anomaly is detected
# with sample private address
automated_response("disconnect", "192.170.1.111")
# 5. Logging the decision
log_decision("Disconnect", "Malicious activity detected from 192.170.1.111")
# 6. Gather threat intelligence
gather_threat_intelligence()
The purpose of this code is to detect the time of login that does not fit in a sequence where the next login time is that of the current. It also has a defined internal control. An analyst will manually investigate all such events (i.e., flagged suspicious activities) to determine whether they are false positives or genuine issues.
\
As AI evolves, key trends are shaping the future of cybersecurity:
Autonomous Security Agents
AI systems will operate as independent agents that make decisions through multi-step processes and manage emergencies by using current data. The systems will execute automated security responses, including isolating infected endpoints, but will require human supervision to verify compliance with established policies.
Federated Learning and Collaborative Threat Intelligence
Federated learning enables organizations to train their AI models without sharing sensitive data by allowing them to collaborate. This approach enhances security threat intelligence by collecting data from diverse sources and employing advanced predictive functions.
Proactive and Predictive Defense
The defense system will shift from reactive to proactive methods, employing predictive modelling to identify emerging threats. AI analyses historical attack patterns to identify security vulnerabilities, thereby determining which weaknesses should be addressed first.
Unified Security Platforms
Integrated security platforms combine SIEM, SOAR, IAM, and vulnerability management into unified systems that operate through artificial intelligence. The system achieves three benefits through its automated response capability, which links data from various platforms.
These trends point to smarter, more efficient, and proactive security systems.
This can be accomplished by developing a model to infer the presence of network vulnerabilities in anticipation of arising attacks using Python snippets:
import pandas as pd
from sklearn. ensemble import RandomForestClassifier
# Historical attack data (vulnerability score, patch status, success)
data = pd.DataFrame({
'vulnerability_score': [0.8, 0.6, 0.9, 0.4, 0.7],
'patch_available': [1, 1, 0, 0, 1],
'successful_attack': [1, 0, 1, 0, 0]
})
# Train RandomForest model
X = data[['vulnerability_score', 'patch_available']
y = data['successful_attack']
model = RandomForestClassifier().fit(X, y)
# Predict risk for new vulnerability
new_vul = pd.DataFrame({'vulnerability_score': [0.85], 'patch_available': [1]})
prediction = model.predict(new_vul)
# Print result
print("High risk. Prioritize patching." if prediction == 1 else "Low risk. Monitor.")
\ The RandomForestClassifier in this code predicts the probability of attack success by analyzing two factors: the vulnerability score and patch status. The system enables security teams to priorities which vulnerabilities to patch first by identifying the most dangerous threats.
\
To maximize value and manage risks, organizations should follow these key practices:
Define Clear Objectives
Start with critical use cases that include alert triage, threat hunting and incident response. Select automation areas that will deliver immediate benefits while increasing the team's operational productivity.
Ensure Data Quality and Governance
AI models should be trained on reliable, representative data, and their performance should be continuously monitored to ensure accuracy. To be successful, organizations must implement strong data governance practices.
Balance Automation with Human Oversight
A Human-in-the-Loop (HITL) framework should be implemented to enable artificial intelligence to assist human decision-making while allowing human experts to handle emergencies.
Invest in Training
Develop hybrid skills by combining cybersecurity knowledge with AI expertise. The system enables teams to manage artificial intelligence tools while efficiently assessing their operational impact.
Monitor and Adapt
AI models and workflows must be modified as new threats emerge. Security systems require frequent updates to maintain protection against emerging threats while security controls remain operational.
Organizations that follow these practices will achieve better security through AI and automation technologies.
Cybersecurity defense operations have achieved a new level of effectiveness through AI and intelligent automation, as these technologies enable defenders to operate at machine speed while improving threat detection and enabling faster, more accurate threat responses. Although these technologies are beneficial to defense systems, they introduce new security risks, ethical challenges, and organizational difficulties that must be managed with caution.
The integration of human expertise and intelligent systems will enable advanced security systems that protect against future cybersecurity threats. Organizations need to move away from their current security methods, which only respond to incidents, by adopting new security systems that combine AI and automation through strategic design and management to protect against emerging security threats while maintaining their protection capacity.
2026-02-19 18:01:19
Last quarter, I got the rare opportunity every data engineer secretly dreams about: a blank slate. A growing Series B startup hired me to build their data platform from scratch. No legacy Airflow DAGs to untangle. No mystery S3 buckets full of abandoned Parquet files. No "we've always done it this way."
Just a question: What do we need to build so this company can make decisions with data?
This is the story of what I chose, what I skipped, and—most importantly—why. If you're starting fresh or considering a major re-architecture, I hope my reasoning saves you some of the dead ends I've hit in previous roles.
Before I made any technology decisions, I spent two weeks just listening. I talked to the CEO, the head of product, the sales lead, the marketing team, and the three backend engineers. I wanted to understand:
Here's what I learned. The company had a PostgreSQL production database, a handful of third-party SaaS tools (Stripe, HubSpot, and Segment), about 50 million events per day flowing through Segment, and exactly one person who would be managing this platform day-to-day: me. With a part-time analytics hire planned for Q3.
That last point shaped every decision. This wasn't a platform for a 15-person data team. It had to be operable by one engineer without turning into a second full-time job just to keep the lights on.
The temptation when you're building from scratch is to reach for the most powerful tools. I've made that mistake before—setting up Kafka for a workload that could've been handled by a cron job and a Python script.
This time I went boring on purpose.
For SaaS sources (Stripe, HubSpot): I chose Fivetran. Yes, it's a managed service, and it costs money. But writing and maintaining custom API connectors for a dozen SaaS tools is a full-time job I didn't have headcount for. Fivetran syncs reliably, handles API pagination and rate limiting, manages schema changes, and pages me only when something genuinely breaks.
For event data: Segment was already in place, so I configured it to dump raw events directly into the warehouse. No custom event pipeline. No Kafka. Not yet.
For the production database: I set up a simple Change Data Capture (CDC) pipeline using Airbyte, replicating key PostgreSQL tables into the warehouse on a 15-minute schedule. Airbyte's open-source version ran on a small EC2 instance and handled our volume without breaking a sweat.
What I deliberately skipped: Kafka, Flink, Spark Streaming, and anything with the word "real-time" in the sales pitch. Our business didn't need sub-second data freshness. Fifteen-minute latency was more than sufficient for every use case anyone could articulate. I've seen too many teams build a real-time streaming infrastructure and then use it to power a dashboard that someone checks once a day.
The rule I followed: don't build for the workload you imagine. Build for the workload you have, with a clear upgrade path to the workload you expect.
After my experience with lakehouse hype (I've written about this before), I made a pragmatic call: BigQuery as the central warehouse.
Why BigQuery over a lakehouse setup?
Operational simplicity. BigQuery is serverless. No clusters to size, no Spark jobs to tune, and no infrastructure to manage. For a one-person data team, this matters enormously. Every hour I spend managing infrastructure is an hour I'm not spending on modeling data or building dashboards.
Cost predictability. With on-demand pricing and a modest reservation for our known workloads, our monthly bill was predictable and reasonable for our data volume.
The ecosystem. BigQuery integrates natively with Fivetran, dbt, Looker, and basically every BI tool. No glue code needed.
What I'd reconsider: If our event volume grows past 500 million events per day, or if the ML team (currently nonexistent) needs to run training jobs on raw event data, I'd revisit this. The upgrade path would be landing raw data in GCS as Parquet (via Segment's GCS destination) and layering Iceberg on top, while keeping BigQuery as the serving layer. But that's a problem for future me, and I'm not going to build for it today.
This was the easiest decision. dbt Core, running on a schedule, transforms raw data into analytics-ready models inside BigQuery.
I've used Spark for transformations. I've used custom Python scripts. I've used stored procedures (dark times). For structured analytical transformations at our scale, nothing comes close to dbt in terms of productivity, testability, and maintainability.
Here's how I structured the project:
Staging models—one-to-one with source tables. Light cleaning: renaming columns, casting types, and filtering out test data. Every staging model has a schema test for primary key uniqueness and not-null on critical fields.
Intermediate models — business logic lives here. Joining events to users, calculating session durations, and mapping Stripe charges to product plans. These are where the complexity hides, so I document every model with descriptions and column-level docs.
Mart models are final, business-friendly tables organized by domain. mart_finance.monthly_revenue, mart_product.daily_active_users, mart_sales.pipeline_summary. These are what analysts and dashboards query directly.
\
What made this work: I wrote dbt tests from day one. Not retroactively, not "when I have time." From the first model. unique, not_null, accepted_values, and relationships tests caught three upstream data issues in the first month alone — before any analyst ever saw the bad data.
This is where I broke from my own habits. I've used Airflow for years. I know it deeply. But for a greenfield project in 2026, I chose Dagster.
Why the switch:
Dagster's asset-based model maps to how I actually think about data. Instead of defining "tasks that run in order," I define "data assets that depend on each other." It sounds like a subtle difference, but it changes how you debug problems. When something breaks, I look at the asset graph and immediately see what's affected. In Airflow, I'd be tracing task dependencies across DAG files.
Dagster's built-in observability is excellent. Asset materialization history, freshness policies, and data quality checks are first-class features, not bolted-on extras.
The development experience is better. Local testing, type checking, and the dev UI make iteration fast. In Airflow, my dev loop was: edit DAG file, wait for scheduler to pick it up, check the UI for errors, repeat. In Dagster, I run assets locally and see results immediately.
What I miss about Airflow: The community is massive. Every problem has a Stack Overflow answer. Dagster's community is growing fast, but it's not at that scale yet. There have been a few times I've had to dig through source code instead of finding a quick answer online.
My orchestration setup: Dagster Cloud (the managed offering) runs my dbt models, Airbyte syncs, and a handful of custom Python assets. Total orchestration cost is less than what I'd spend on the EC2 instances to self-host Airflow, and I don't have to manage a metadata database or worry about scheduler reliability.
For BI, I chose Looker (now part of Google Cloud). Controversial in some circles because of the LookML learning curve, but here's why it was the right call for us.
The semantic layer is the product. LookML lets me define metrics, dimensions, and relationships in version-controlled code. When the CEO asks "what's our MRR?" and the sales lead asks the same question, they get the same number. Not because they're looking at the same dashboard, but because the metric is defined once, in one place.
I've lived through the alternative: a BI tool where anyone can write their own SQL, and three people calculate revenue three different ways. That's not a tooling problem. It's a semantic layer problem. And Looker solves it better than any tool I've used.
What I'd also consider: If I were optimizing for cost or for a less technical analyst team, I'd look at Metabase (open source, SQL-native, dead simple) or Evidence (code-based BI, great for a data-engineer-heavy team). Looker's pricing isn't cheap, and the LookML abstraction is overkill if your team just wants to write SQL and make charts.
Here's the part that doesn't show up in architecture diagrams but made the biggest difference.
I set up a lightweight data catalog using dbt's built-in docs site, deployed as a static page on our internal wiki. Every mart model has a description. Every column has a definition. It took about 30 minutes per model to document, and it's already saved hours of "hey, what does this column mean?" Slack messages.
When data breaks — and it does — there's a clear process. An alert fires in Slack. I acknowledge it within 30 minutes during business hours. I post a status update in the #data-incidents channel. When it's resolved, I write a brief post-mortem: what broke, why, and what I'm doing to prevent it.
This sounds like overkill for a one-person team. It's not. It builds trust. When stakeholders see that data issues are handled transparently and quickly, they trust the platform. Trust is the most important metric a data platform has.
Every technology decision I made — BigQuery over Snowflake, Dagster over Airflow, Fivetran over custom connectors — has a one-page ADR in our repo. Each one explains the context, the options I considered, the decision, and the trade-offs.
When the next data engineer joins (hopefully soon), they won't have to reverse-engineer why things are the way they are. They can read the ADRs, understand the reasoning, and make informed decisions about what to change.
No build is perfect. Three months in, here's what I'd adjust.
I'd set up data contracts earlier. I wrote about schema validation in a previous article, and I should've practiced what I preached. We had two incidents where backend engineers changed column types in PostgreSQL without telling me. A formal data contract between the backend team and the data platform would've caught this at deploy time instead of at sync time.
I'd invest in a reverse ETL tool sooner. The sales team wanted enriched data pushed back into HubSpot within the first month. I hacked together a Python script, but a tool like Census or Hightouch would've been cleaner and more maintainable.
I'd timebox the BI tool decision. I spent three weeks evaluating BI tools. In hindsight, two of those weeks were diminishing returns. The key requirements were clear after week one. I should've committed sooner and iterated.
| Layer | Tool | Why | |----|----|----| | SaaS Ingestion | Fivetran | Reliable, zero-maintenance | | Database Replication | Airbyte (OSS) | Flexible CDC, cost-effective | | Event Collection | Segment → BigQuery | Already in place, direct sync | | Storage & Compute | BigQuery | Serverless, simple, sufficient | | Transformation | dbt Core | Best-in-class for SQL transforms | | Orchestration | Dagster Cloud | Asset-based, great DX, managed | | BI & Semantic Layer | Looker | Metric definitions in code | | Data Quality | dbt tests + Elementary | Automated checks at every layer | | Documentation | dbt docs | Version-controlled, always current |
Total monthly cost: Under $3,000 for the entire platform, supporting ~50M events/day and a growing team of data consumers.
The best data platform isn't the one with the most sophisticated architecture. It's the one that actually gets used, actually gets trusted, and can actually be maintained by the team you have — not the team you wish you had.
If I could distill everything I learned from this build into one principle, it's this: pick boring tools, invest in trust, and leave yourself an upgrade path. The fancy stuff can come later. The fundamentals can't wait.
2026-02-19 17:52:27
\ Big Tech will spend over $600 billion on AI infrastructure in 2026 — a 36% jump from last year. The vast majority of that capital is flowing toward one thing: GPUs. For investors who already understand hardware-based yield and decentralized infrastructure, this represents a familiar opportunity in an unfamiliar market.
Graphics processing units were originally designed to render video game graphics. Today, they are the computational backbone of artificial intelligence. Every large language model, every image generator, every autonomous driving system depends on clusters of GPUs running in parallel. NVIDIA alone posted $39.1 billion in data center revenue in a single quarter earlier this year.
The global data center GPU market was valued at approximately $14.5 billion in 2024. Analysts project it will exceed $155 billion by 2032 — a compound annual growth rate of around 30.6%. That kind of trajectory is rare outside of crypto itself.
The demand is coming from all directions. Training a single large language model can require thousands of high-end GPUs running continuously for weeks. Inference — actually running a trained model for end users — demands even more aggregate compute as AI applications scale to hundreds of millions of users.
Hyperscalers are responding with unprecedented spending. Microsoft, Meta, Google, and Amazon are collectively projected to invest more than $500 billion in AI infrastructure this year. Meta increased its capital expenditure by 111% year-over-year in a recent quarter, almost entirely on servers, data centers, and networking equipment.
Meanwhile, supply remains constrained. Advanced chip manufacturing is concentrated in a handful of foundries. Power availability is emerging as a bottleneck, with data center projects across Europe and the United States stuck in grid-connection queues. Even large-volume buyers face extended lead times for NVIDIA's most powerful GPUs.
The takeaway: GPUs are no longer semiconductor components. They are critical infrastructure — comparable to power plants, cell towers, or fiber optic networks. And like all critical infrastructure, they can be owned, deployed, and monetized.
The model is straightforward. You invest in physical GPU hardware, either directly or through a platform. That hardware gets deployed in data centers or cloud environments. AI companies, researchers, and developers rent the compute power on demand. Rental revenue flows back to investors.
If you have ever operated a mining rig, the structure will feel intuitive. You own hardware. That hardware performs computational work. You earn yield. The critical difference lies in the source of demand. In crypto mining, earnings depend on block rewards and network difficulty — both of which decline over time by design. In GPU rental for AI, demand comes from commercial workloads, and companies are willing to pay premium rates for access to scarce compute.
Industry data suggests that one hour of GPU rental for AI workloads can generate 1.5 to 4 times the revenue of the same hour spent on crypto mining, with significantly less exposure to token price volatility. A KPMG survey found that approximately 80% of investors identify generative AI as the primary reason to invest in GPU capacity.
GPUnex is a GPU compute marketplace that connects three types of participants: renters who need compute, providers who supply hardware, and investors who want exposure to GPU infrastructure economics.
For renters, the platform offers enterprise-grade NVIDIA GPUs — including H100, A100, L40S, and L4 — for AI training, inference, 3D rendering, and research workloads. Deployment takes minutes with per-second billing and full root access via SSH.
For providers, GPUnex lets anyone with idle GPU hardware list it on the marketplace, set their own pricing and availability, and receive automatic weekly payouts in USDC.
For investors — and this is the part that should interest crypto-native audiences most — GPUnex offers a structured way to participate in GPU infrastructure without physically owning or managing hardware.
\
GPUnex's investment offering is designed to lower the barrier to entry for GPU infrastructure. Instead of purchasing, housing, and maintaining physical servers, investors can participate in GPU infrastructure packages and earn daily returns backed by real hardware utilization and marketplace demand.
Here is what that looks like in practice:
The structure mirrors what DeFi users are already comfortable with — staking or lending protocols that generate yield. The difference is that the underlying revenue comes from commercial AI compute demand, not protocol emissions or token inflation.
Investor onboarding is handled through GPUnex's investor portal, with KYC verification and security built into the process.
\
To put GPU infrastructure investment in context, here is how it stacks up against two familiar income strategies in the crypto space.
| Factor | GPU Infrastructure Investment | Crypto Staking | GPU Mining | |----|----|----|----| | Underlying Asset | Physical GPU hardware | Native blockchain tokens | Physical GPU hardware | | Income Source | AI compute rental fees | Network validation rewards | Block rewards + tx fees | | Demand Driver | AI model training and inference | Network security and throughput | Blockchain consensus | | Market Trend (2026) | Growing ~30% per year | Stable, yields normalizing | Declining profitability | | Entry Barrier | Low (via platform) to High (own hardware) | Low (any token amount) | Medium (hardware + electricity) | | Key Risk | Hardware depreciation, utilization rates | Token volatility, slashing | Difficulty increases, energy costs |
None of these strategies dominates in every dimension. Staking remains the lowest-friction yield option. Mining still works for those with cheap electricity. GPU infrastructure investment sits between them — higher potential returns driven by structural AI demand, but with hardware lifecycle risk that requires attention.
If you follow Web3 trends, you have likely encountered DePIN — Decentralized Physical Infrastructure Networks. The idea is that instead of centralized companies owning all physical infrastructure, individuals contribute hardware to a network and earn fees or tokens in return.
GPU marketplaces and DePIN share the same thesis. Both depend on distributed hardware owners providing capacity. Both generate yield from real utilization rather than emissions. And both are gaining traction as centralized infrastructure fails to scale fast enough. Europe, for instance, has roughly 3,000 data centers operating at about 84% utilization, while over 30 gigawatts of new projects remain stuck waiting for grid connections.
For crypto investors, the mechanics are already native. Providing capacity, staking hardware, earning yield from network participation — these concepts come straight from DeFi. GPU infrastructure simply applies them to a market with accelerating commercial demand.
Platforms like GPUnex make the connection explicit: investors gain exposure to GPU compute revenue through structured packages, while the platform handles hardware deployment, maintenance, and renter relationships. The format resembles staking or lending, but the returns are driven by businesses paying for AI compute, not by inflationary token models.
GPU infrastructure investment is not risk-free, and the risks deserve clear attention.
Hardware depreciation is the most immediate concern. NVIDIA releases new GPU architectures every 18 to 24 months, each bringing significant performance gains that can reduce the rental value of older hardware. Unlike tokens, physical GPUs lose value over time.
Utilization risk matters too. GPUs only generate revenue when they are actively rented. Periods of lower demand or oversupply push utilization rates down, directly impacting returns.
Market concentration is a structural factor. Current AI demand is driven disproportionately by a small number of hyperscalers and well-funded AI companies. A pullback from these players would ripple through the entire GPU economy.
Regulatory uncertainty around AI compute, data sovereignty, and energy consumption is growing globally and could affect where and how GPU infrastructure is deployed.
This article is not financial advice. Any investment decision should follow thorough independent research.
GPU infrastructure is emerging as a legitimate alternative asset class, supported by one of the strongest demand signals in modern technology. The AI compute market is projected to grow from $14.5 billion to over $155 billion in under a decade. Big Tech capital expenditure plans confirm this is not speculative — the spending is happening now.
For crypto investors, the parallels are striking. You already understand hardware-based yield, decentralized infrastructure, and digital asset classes. GPU investment applies those principles to a market with accelerating structural demand rather than diminishing block rewards.
Platforms like GPUnex are making this accessible by offering daily returns, instant USDC withdrawals, and transparent dashboards — a format that feels native to anyone who has used DeFi protocols. The difference is that the revenue comes from AI companies paying for compute, not from token inflation.
2026 is still early for this trend. As AI infrastructure spending intensifies and GPU supply remains constrained, investors who already understand decentralized infrastructure are positioned for what comes next.
\
2026-02-19 17:38:59
Cross-border payments have never moved faster.
Settlement cycles are shrinking. Messaging standards are richer. Transparency is an explicit policy goal. From the outside, it looks like the problem is being solved.
Yet ask a mid‑market exporter a simple question — “What did this FX transaction actually cost us, end to end?” — and the answer is often buried across spreadsheets, bank portals, manual reconciliations, and post‑trade analysis.
Infrastructure has improved. Business outcomes haven’t.
This isn’t accidental. It’s structural.
For years, the limitations of cross‑border payments could be explained away by legacy rails. That explanation no longer holds.
Payment infrastructure has materially upgraded. Structured messaging standards are live. Faster settlement is the norm, not the exception. Transparency is measured and tracked by regulators.
And yet, the operational experience inside companies has barely changed.
That mismatch — between modern infrastructure and outdated enterprise outcomes — is becoming a real business constraint, especially for firms operating across multiple banks and currencies.
Cross‑border payments are a formal policy priority. Global regulators have defined clear objectives: faster execution, lower costs, better transparency, and improved resilience for end users, including businesses engaged in international trade.
Official monitoring shows progress at the infrastructure level. But it also shows something else: key outcome‑oriented targets — particularly around FX transparency, traceability, and reconciliation — remain only partially met.
This matters because once a problem shows up consistently in official KPI tracking, it’s no longer anecdotal. It’s systemic.
Companies rarely issue white papers declaring that their payment processes are broken. Instead, they adapt.
Across industries, corporate treasury teams continue to operate labor‑intensive models to manage cross‑border payments and FX exposure. Independent surveys and policy analyses consistently rank fragmented data, limited visibility, and manual reconciliation among the most time‑consuming and least mature treasury activities.
Common patterns are easy to recognize:
These practices persist despite years of investment in treasury technology. That persistence is the signal.
Organizations don’t repeatedly allocate skilled labor and advisory spend to marginal problems. They do it when the problem is recurring, economically material, and insufficiently addressed by existing infrastructure.
Modern payment standards can carry far more information than their predecessors. In transit, payment data is richer, more structured, and more expressive than ever before.
The break happens after settlement.
Once payments reach the enterprise boundary, data arrives from multiple banks, formats, and channels. Enterprise systems — ERPs, treasury platforms, internal analytics — often consume that data inconsistently or not at all.
The result is familiar: rich data at the network level, but fragmented and lossy data at rest.
From a business perspective, faster settlement without usable data doesn’t reduce work.
It accelerates the arrival of reconciliation problems.
This is the missing layer in cross‑border payments: a neutral, enterprise‑oriented data backbone that can ingest, normalize, and reconcile information across institutions and systems.
Not all firms experience this gap equally.
Large global institutions can internalize complexity. They build bespoke integrations, maintain dedicated teams, and absorb fragmentation through scale. Smaller firms may tolerate inefficiency because volumes are limited.
Mid‑market companies sit in between.
They operate across multiple currencies and banking relationships, face audit and reporting expectations comparable to larger firms, and yet lack the scale to justify heavy internal infrastructure. For them, fragmented data isn’t an inconvenience — it’s an operational constraint.
For U.S. mid‑market exporters in particular, this constraint directly affects competitiveness. Limited enterprise‑level transparency amplifies execution uncertainty, working‑capital friction, and operational risk in cross‑border trade.
This gap won’t be closed by another execution venue or faster payment rail.
It requires an infrastructure layer focused on data usability inside the enterprise.
At a minimum, that means:
This isn’t about trading or execution.
It’s about making modern payment data usable where it actually matters: inside the business.
Closing the last‑mile gap delivers more than cleaner reconciliations.
At a system level, better enterprise‑side transparency supports:
In that sense, the last mile of cross‑border payments isn’t a private optimization problem.
It’s a prerequisite for realizing the public objectives that motivated infrastructure reform in the first place.
Cross‑border payments are improving. The rails are faster, the standards richer, and the policy direction clear.
But until enterprises can reliably consume, reconcile, and govern the data that accompanies those payments, the promised outcomes will remain incomplete.
When infrastructure upgrades fail to translate into business‑level transparency and resilience, the gap itself becomes systemic.
Closing that gap isn’t incremental refinement. It’s how policy intent finally turns into economic reality.
This article draws on public materials and analysis from global policy bodies, regulators, and independent industry research, including:
Sources are provided for contextual grounding. Interpretations and conclusions are the author’s own.
