Mert 
Volvo, Google Gemini destekli yeni sistemle araçların kameradan gördüklerini analiz edip açıklamasını sağlıyor. Yapay zekâ tabelaları okuyup çeviriyor ve çevre hakkında bilgi verebiliyor.
CES 2026 Fuarı’nda yapay zeka odaklı hazırlanan bilgisayar modeli AMD Ryzen AI Halo da tanıtılmıştı. Doğrudan Nvidia’nın DGX Spark’ına rakip olarak tasarlanan küçük boyutlu yapay zeka sistemi, AMD’nin yeni açıklamasına göre gücünü Ryzen AI Max+ 395’ten alıyor ve 200 milyar parametreli yapay zeka modellerini lokal olarak çalıştırabiliyor. AMD, cihazın DGX Spark ile kıyaslandığında GPT OSS 120B modelinde token bazında %7’ye varan seviyede daha yüksek performans verdiğini iddia ediyor. Şirket, Qwen 3.5 122B modelinde ise farkın %12’ye kadar çıktığını belirtiyor. Geliştiricilere yönelik tasarlanan ürünü 128 GB LPDDR5x RAM ile pazara sunacak olan AMD, cihazın hem Linux hem de Windows desteğine sahip olduğunu açıklıyor. Bu konuda yalnızca Linux desteği bulunan DGX Spark’tan ayrılan cihaz, 10 Gbps ethernet çıkışıyla geliyor, 2 TB PCIe Gen 4×4 SSD ile üç adet USB-C portu taşıyor ve WiFi 7 / Bluetooth 5.4 kablosuz bağlantı teknolojilerine destek veriyor. HDMI 2.1b de taşıyan 120W TDP değerine sahip AI Halo, […]
Nvidia DGX Spark rakibi AMD Ryzen AI Halo için resmi satış fiyatı açıklandı yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.
İlk sızıntısı geçtiğimiz ay yapılan AMD Ryzen 7 5800X3D AM4 10th Anniversary Edition işlemci modeli, çok yakında resmi olarak tanıtılacak gibi görünüyor. Hindistan merkezli bir satış kanalında resmi kutu görselleriyle birlikte yaklaşık 310 dolardan listelenen işlemci, ilk olarak 2022’de pazara sunulmuş, oyunlarda gösterdiği yüksek performansla büyük beğeni toplamış ve 2023 yılında üretimden kaldırılmıştı. Yeni sürümde performansı iyileştirmeye yönelik bir adım atması beklenmeyen AMD, bu özel sürümü her pazara götürmeyebilir.
AMD Ryzen 7 5800X3D AM4 10th Anniversary Edition çok yakında tanıtılacak gibi görünüyor yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.
Three years into my career, I raised my hand for a job that more senior engineers on the team had quietly decided to avoid.
We’d inherited a system. Two outside vendors had built it, then handed it over to an in-house team with zero documentation. Everyone was new. Nobody fully understood how it worked, and nobody wanted to be the person who touched it and broke production.
Then leadership dropped the mandate: make it scale to 5,000 concurrent users, turn it into multi-tenant SaaS, and support per-client authentication — some tenants on Active Directory, some on LDAP, some with their own mechanism.
The existing system couldn’t do any of that. And the people best equipped to fix it were the most afraid of it.
I took the challenge. Here’s what the black box actually looked like, and the method that got us through it — with one Senior DevOps, in about two months.
What we inherited
If you’ve ever opened a repo and felt your stomach drop, you know the feeling. The instinct in that moment is to rewrite it. That instinct is almost always wrong — a rewrite of a system you don’t understand just recreates the same unknowns, slower, while the business waits.
So we didn’t rewrite. We tamed it. Here’s the method.
1. Understand the system from the outside, not the code
You can read a million lines of undocumented code and still not know what actually happens in production. So I stopped trying to read my way to understanding and started observing instead:
Map the behavior, not the source. Within days you have a real picture of the system the code comments never gave you.
2. Find the seams
Once you can see how requests flow, you look for seams — the natural boundaries where you can change something without unraveling the whole sweater. For us the important ones were the authentication boundary, the heavy reporting read paths, and the frontend vs. backend responsibilities that happened to live in the same process.
You don’t need to understand every line — you need to understand the edges.
3. Scale the box from the outside before touching its insides
The key insight, and the part I’d tell every junior engineer: you can scale a system you don’t fully understand by changing what’s around it, not what’s inside it.
We went from one server to four:
Concretely:
None of this required understanding the messy internals. It’s infrastructure and topology — and it bought us the headroom for 5,000 concurrent users.
4. Isolate the one risky internal change behind an abstraction
The part we did have to change was auth — going multi-tenant meant Active Directory could no longer be hardcoded. Each tenant needed its own mechanism: AD, LDAP, or custom.
Instead of touching AD logic scattered everywhere, we introduced a single seam: a pluggable auth provider, chosen per tenant.
// One interface, one adapter per mechanism.
const authProviders = {
ad: require('./auth/activeDirectory'),
ldap: require('./auth/ldap'),
custom: require('./auth/custom'),
};
function getAuthProvider(tenant) {
const provider = authProviders[tenant.authType];
if (!provider) throw new Error(`No auth provider for ${tenant.authType}`);
return provider;
}
async function login(req, res) {
const tenant = await resolveTenant(req); // by subdomain / header
const provider = getAuthProvider(tenant);
const user = await provider.authenticate(req.body, tenant.config);
// ...issue the session / token
}
Every adapter implements the same authenticate(credentials, config) contract. The old AD logic became one adapter behind the interface instead of an assumption baked through the codebase. Adding a new tenant’s auth no longer means surgery on the core — just one small, isolated adapter.
That’s the legacy-taming move in miniature: don’t refactor the whole thing — wrap the risky part in a boundary and change behavior there.
5. Change incrementally, verify behavior every step
Because nobody understood the system fully, every change went out small and observable. Capture how it behaves now, change one thing, confirm nothing drifted, repeat. Slow is smooth, smooth is fast — especially when the safety net is observability, not people who remember how it works.
Where it landed
And the part I didn’t expect: doing this as a 3-year engineer — taking the thing no one else would touch and bringing it through — changed my standing in the company. It taught me that the scary, undocumented, “don’t touch it” systems are exactly where you earn trust the fastest.
What I’d tell my 3-year-old self
Have you inherited a black box like this? What did you do first — read the code, or watch it run?
Most RAG tutorials start the same way: “First, install a vector database…” Then come the embedding models, the chunking strategies, the similarity thresholds. By the time you can ask a question about a PDF, you’ve deployed three services and written 200 lines of boilerplate.
Garudust Agent takes a different path. RAG is built in — backed by SQLite FTS5 with a trigram tokenizer. No vector database. No embedding API calls. Drop a PDF (or TXT, CSV, Markdown, JSON) into the conversation and start asking questions in seconds.
How It Works
When you ingest a document, Garudust:
tokenize = 'trigram'
When you ask a question, doc_search runs a full-text query against the index and feeds the top matching chunks to the LLM as context. That’s the whole pipeline — one SQLite file at ~/.garudust/state.db.
The trigram tokenizer means it works on any language, including Thai, Chinese, and Japanese, without any tokenizer configuration.
Setup
RAG is enabled by default. The only thing you need to configure is which directories the agent is allowed to read from:
# ~/.garudust/config.yaml
security:
allowed_read_paths:
- /home/you/documents
- /data/company-docs
That’s it. If you want to turn RAG off entirely:
disabled_toolsets: [rag]
Your First Ingestion
Start the CLI:
garudust
Then tell the agent to ingest a file:
You: ingest /home/you/documents/employee-handbook.pdf
Agent: Indexed employee-handbook.pdf — 47 chunks ready for search.
Preview: "This handbook outlines the policies and procedures for all employees…"
Now ask anything:
You: What is the remote work policy?
Agent: According to the employee handbook, remote work is permitted up to 3 days per week
for roles that do not require on-site presence. Employees must notify their manager
at least 24 hours in advance and maintain availability during core hours (10am–4pm).
The Four RAG Tools
| Tool | What it does |
|---|---|
doc_ingest |
Extract and index a file (PDF, TXT, CSV, MD, JSON…) |
doc_search |
Full-text search across all ingested documents |
doc_list |
List all indexed documents with chunk count and timestamp |
doc_forget |
Remove one file or clear the entire index |
You never call these directly — the agent decides when to use them based on your question. But knowing they exist helps you understand what’s happening.
Re-ingesting a file
If a document changes, just ingest it again. The old index for that path is replaced automatically.
Forgetting a document
You: Remove the Q1 report from the index.
Agent: Document removed from index.
Or clear everything:
You: Clear all indexed documents.
Agent: Removed 5 document(s) from index.
FTS5 Query Syntax
doc_search supports full FTS5 syntax, which the agent uses automatically when your question benefits from it:
| Syntax | Example |
|---|---|
| AND (default) | remote work policy |
| Phrase | "annual leave" |
| OR | vacation OR leave |
| NOT | policy NOT contractor |
| Prefix | terminat* |
You don’t need to write FTS5 queries yourself — the agent figures this out. But if you want to guide it:
You: Search for "termination clause" in the contract documents.
Real-World Use Cases
1. Company Knowledge Base
Ingest your onboarding docs, SOPs, and internal wikis. New team members can ask questions in plain language instead of searching through Confluence.
You: ingest /docs/sop-release-process.md
You: What approvals are needed before a hotfix can go to production?
2. Contract and Legal Review
You: ingest /legal/vendor-agreement-2025.pdf
You: Does this contract include a limitation of liability clause? What is the cap?
3. Log Analysis
Ingest a log file and ask questions without writing grep patterns:
You: ingest /var/log/app/error.log
You: Which service caused the most errors in the last hour?
You: Are there any database connection timeouts?
4. Codebase Documentation
You: ingest /project/docs/api-reference.md
You: What parameters does the /auth/refresh endpoint accept?
Ingesting Files Sent via Telegram or LINE
If you’re running garudust-server with a messaging platform, users can send files directly to the bot. Attachments are automatically saved to a temporary path and can be ingested on request:
User sends: quarterly-report.pdf (attached)
Agent: I received your file. Would you like me to index it for search?
User: yes
Agent: Indexed quarterly-report.pdf — 83 chunks ready.
Preview: "Q1 2025 Financial Summary — Total Revenue: $4.2M…"
User: What was the gross margin for Q1?
Agent: According to the report, gross margin for Q1 2025 was 61.3%,
up from 58.9% in Q4 2024.
Platform attachments (files from Telegram, LINE, Discord, etc.) are always allowed regardless of
allowed_read_paths, since they’re written to/tmp/garudust_*by the platform adapter.
Multiple Documents at Once
You can ingest multiple files and search across all of them in the same session:
You: ingest /docs/policy-2024.pdf
You: ingest /docs/policy-2025.pdf
You: What changed in the travel expense policy between 2024 and 2025?
The agent searches both documents and synthesizes the differences.
Check what’s indexed at any time:
You: What documents have you indexed?
Agent: 2 documents indexed:
- policy-2024.pdf | 34 chunks | ingested 2025-05-21 09:14
- policy-2025.pdf | 38 chunks | ingested 2025-05-21 09:15
Limitations
state.db, but searches are scoped to the current conversation key. Starting a new session means re-ingesting if you want to query the same files. Summary
| Garudust RAG | Vector DB approach | |
|---|---|---|
| Setup | One config line | Vector DB + embedding API |
| Storage | SQLite (single file) | Separate service |
| Languages | Any (trigram) | Depends on embedding model |
| Cost | Zero (no embedding calls) | Per-token embedding cost |
| Search type | FTS5 keyword + LLM reasoning | Semantic similarity |
Garudust’s RAG won’t replace a purpose-built vector search pipeline for large-scale production retrieval. But for a developer who wants to ask questions about their documents right now — without running a second service — it’s the fastest path from PDF to answer.
Sharing my experience as senior software engineer worked with 10 years in Bloomberg, Kraken and integrated most of the exchanges world wide
The Financial Information eXchange (FIX) protocol is one of the most widely used communication standards in global financial markets.
It powers:
According to QuickFIX, the open-source implementation of FIX:
“The Financial Information Exchange (FIX) Protocol is a message standard developed to facilitate the electronic exchange of information related to securities transactions.”
While that definition sounds straightforward, the scale at which FIX operates in modern electronic trading is massive.
Over the last 10 years working at Bloomberg and more than a year working with Kraken’s institutional trading infrastructure, I’ve worked extensively with FIX connectivity across more than 30 global exchanges and venues spanning:
This article explains:
The Pain Point FIX Solved
Before FIX became mainstream, trading workflows were heavily manual.
Orders were communicated through:
This caused major operational problems:
As electronic markets evolved, firms needed:
FIX solved this problem by creating a universal messaging standard between counterparties.
Today, almost every major financial institution supports FIX in some form.
Firms Driving FIX Adoption
The FIX Trading Community includes firms such as:
Initially designed for equities, FIX now powers:
Even modern crypto venues expose FIX gateways for institutional clients because many hedge funds and execution algos already rely on FIX-native infrastructure.
At Kraken, for example, FIX connectivity is critical for institutional order flow where reliability and deterministic behavior matter more than retail-friendly APIs.
What Exactly Is a FIX Message?
At its core, FIX is just structured key-value messaging.
A FIX message consists of:
Each field contains:
Example:
8=FIX.4.4|35=D|55=AAPL|54=1|38=100|
Where:
In reality, the delimiter is a non-printable SOH character rather than “|”.
Anatomy of a FIX Message
A typical FIX order message looks like this:
8=FIX.4.4
9=176
35=D
49=CLIENT1
56=EXCHANGE
34=215
52=20260521-12:01:01.001
11=ORD12345
55=BTCUSD
54=1
38=10
40=2
44=65000
59=0
10=128
Interpretation:
The trailer checksum validates message integrity.
Real-World FIX Is Much More Complex
Most tutorials stop at simple examples.
Production FIX systems are significantly more complicated.
Over the years integrating 30+ exchanges, I encountered:
Even when two exchanges claim FIX 4.4 compliance, behavior can differ dramatically.
The protocol is standardized.
Implementations are not.
That is where most engineering complexity begins.
FIX Engines and Session Management
One of the most widely used FIX engines is QuickFIX.
A simplified Python FIX application interface looks like:
class Application(_object):
def onCreate(self, sessionID): return
def onLogon(self, sessionID): return
def onLogout(self, sessionID): return
def toAdmin(self, message, sessionID): return
def toApp(self, message, sessionID): return
def fromAdmin(self, message, sessionID): return
def fromApp(self, message, sessionID): return
These callbacks handle:
FIX sessions are stateful.
This is one of the most important aspects new engineers often overlook.
Every session maintains:
At Bloomberg, ensuring session resiliency during volatile market conditions was critical because even a temporary sequence mismatch could impact downstream order routing.
At Kraken, maintaining deterministic session behavior across crypto market volatility introduced another layer of operational complexity.
Why Low-Latency FIX Parsers Avoid String Splits
One major misconception is that FIX parsing is “simple”.
Technically yes.
Operationally no.
In high-frequency trading systems, performance matters enormously.
Naive implementations use:
message.split("|")
But low-latency trading systems avoid repeated string splitting because:
Instead, production-grade systems often use:
At Bloomberg, low-latency parsing became especially important during high market throughput events where millions of FIX messages could flow through systems in very short intervals.
Repeating Groups — Where FIX Gets Interesting
FIX supports repeating groups.
These allow nested structures inside messages.
Examples include:
Example conceptually:
NoLegs=2
LegSymbol=BTCUSD
LegSide=1
LegSymbol=ETHUSD
LegSide=2
Repeating groups are one reason why FIX parsers become non-trivial.
The parser must understand:
Many exchange-specific bugs emerge precisely from malformed repeating groups.
Custom FIX Tags in Real Trading Systems
One of the most practical aspects of FIX engineering is custom tags.
Although FIX defines standard tags, almost every exchange or broker introduces proprietary extensions.
Examples include:
Custom tags usually exist in higher numeric ranges:
For example:
9001=InternalStrategyID
9100=SmartOrderFlag
9205=RiskProfile
Across Bloomberg integrations and later crypto exchange connectivity, I frequently worked with:
This often required:
One challenge with custom tags is ensuring they do not break:
This becomes increasingly difficult when supporting dozens of venues simultaneously.
FIX Across Traditional Finance and Crypto
One interesting evolution over the past decade is how crypto markets adopted institutional FIX infrastructure.
Initially, crypto APIs were primarily REST and WebSocket based.
But institutional participants demanded:
As a result, many crypto exchanges introduced FIX gateways.
However, crypto FIX implementations sometimes differ significantly from traditional finance:
Working across both TradFi and crypto FIX ecosystems highlighted how adaptable the protocol remains despite being decades old.
Sample Order Cancel Request Using QuickFIX
Example Python code:
from quickfix import *
def sendOrderCancelRequest():
message = quickfix.Message()
header = message.getHeader()
header.setField(quickfix.BeginString("FIX.4.2"))
header.setField(quickfix.SenderCompID("CLIENT"))
header.setField(quickfix.TargetCompID("EXCHANGE"))
header.setField(quickfix.MsgType("F"))
message.setField(quickfix.OrigClOrdID("123"))
message.setField(quickfix.ClOrdID("321"))
message.setField(quickfix.Symbol("BTCUSD"))
message.setField(quickfix.Side(Side_BUY))
message.setField(quickfix.Text("Cancel My Order"))
Session.sendToTarget(message)
Notice:
In production systems, additional logic typically exists for:
Why FIX Still Dominates
Despite newer protocols and APIs, FIX remains dominant because:
Even modern low-latency systems frequently use:
FIX acts as the interoperability layer between institutions.
Final Thoughts
FIX may appear simple at first glance:
But at scale, FIX engineering becomes deeply sophisticated.
After spending:
I’ve seen firsthand how much engineering effort goes into:
The protocol has survived multiple generations of market evolution because it solved a fundamental problem exceptionally well:
standardized electronic communication between trading systems.
And despite its age, FIX continues to remain at the core of global electronic trading infrastructure.
Thanks for reading.
Pritesh Gaur
Privacy is not a luxury feature for AI chat.
It is the point.
People do not only ask AI about public facts. They ask it about decisions they are unsure about, ideas they are not ready to share, emotions they are still sorting through, messages they have not sent, stories they are inventing, plans they may abandon, and questions they would never type into a public timeline.
That kind of conversation deserves a different default.
Secret AI is built around a simple belief: your private AI conversations should stay yours.
The Problem With Always-Online AI
Most AI products are designed around the cloud.
You type a message. The message leaves your device. It is processed somewhere else. The answer comes back. That design can be powerful, but it also creates an uncomfortable question:
Where did my words go?
For everyday questions, maybe that does not matter. But AI chat is quickly becoming more personal than search. People use it to rehearse hard conversations, write private notes, explore roleplay, process stress, study sensitive topics, and test ideas before they are ready for anyone else.
The more useful AI becomes, the more personal the conversation becomes.
That is why privacy cannot be treated as a checkbox at the bottom of a settings page. It has to shape the product itself.
Secret AI Does Not Need Your Conversations
Secret AI is designed so you can chat with local open-source models on your own device.
When you use local mode, your conversation does not need to be sent to a remote AI chat service. It does not need to become training material. It does not need to be stored in someone else’s account history. It does not need to be inspected, ranked, mined, or repackaged.
It can simply stay with you.
That changes the emotional feel of AI.
You can ask the messy question without wondering who is watching. You can draft the honest version before you write the polished version. You can roleplay, brainstorm, vent, study, plan, or explore an idea without turning every sentence into platform data.
AI should be useful without being nosy.
Offline Chat Means Freedom To Think
Offline AI is not only about security. It is also about freedom.
When your assistant can run locally, you can use it in places where the internet is weak, unavailable, expensive, or simply not welcome. You can chat on a flight, during a commute, in a quiet room, while traveling, or when you intentionally want to disconnect.
You can also talk about things that feel too personal for a normal cloud chatbot:
The point is not that every conversation is dramatic. The point is that small private thoughts are still private.
A Personal AI Space, Not A Data Pipeline
The best AI companion is not always the biggest model in the cloud.
Sometimes the best assistant is the one that is close to you, available when you need it, and quiet about what you say.
Secret AI gives you a private place to think with AI. You can shape an assistant for writing, study, decision-making, reflection, language practice, roleplay, or creative exploration. You can make characters for repeated situations. You can keep the experience personal without giving up control of the conversation.
This matters because personalization should not require surveillance.
An AI can feel helpful, warm, and tailored without collecting everything you say. It can be useful without building a profile around your private thoughts. It can support you without turning your chat history into a product.
That is the line Secret AI is built to respect.
Local First, Flexible When You Need More
Local AI is the privacy-first foundation.
For many conversations, a local open-source model is enough: brainstorming, drafting, roleplay, rewriting, reflection, study help, and everyday thinking. The benefit is clear: the chat can happen on your device, under your control.
There are also times when people want stronger cloud models for harder tasks. Secret AI can support API-based tokens for those moments. When you choose a cloud model, the provider’s own data rules still matter. But the important difference is choice.
You should be able to decide when capability matters more and when privacy matters most.
That should not be hidden from you.
Chat About Anything Without Performing For The Internet
The internet has trained people to perform.
Even private apps often feel connected to something larger than you: an account, a server, a feed, an analytics system, a recommendation engine, a sync layer, a data policy you did not read.
AI chat should not always feel like that.
Sometimes you just want to open your phone and talk through something. No audience. No platform. No pressure to make the thought clean before it exists.
Secret AI is for that kind of moment.
Talk through a decision. Build a fictional character. Practice a hard conversation. Ask an embarrassing beginner question. Draft a note. Explore a strange idea. Reflect on your day. Try a roleplay scene. Study something difficult. Think out loud.
Not everything needs to leave your device.
The Future Of Personal AI Should Be Private
AI is becoming more intimate because it is becoming more useful.
That makes privacy more important, not less.
The future should not be a world where every personal question is routed through a remote service by default. It should be a world where people can choose local AI, keep conversations offline, and use intelligent tools without surrendering their private thinking.
Secret AI is built for that future.
Private by design.
Local when you want it.
Offline when you need it.
Yours by default.
WaBetaInfo tarafından yapılan keşfe göre WhatsApp, yakında “kaybolan mesaj” altyapısına yeni bir imkan daha ekleyecek. Bu temelde gönderilen bir mesajın karşı taraftan örneğin okunduktan 5 dakika sonra ya da okunduktan 10 dakika sonra otomatik olarak silinmesi mümkün olacak. Yani bu yeni süreçte otomatik silme sayacı gönderme zamanına göre değil, okunma durumuna bakılarak başlatılacak. Bu altyapıda da okunmayan mesajlar 24 saat içerisinde otomatik olarak silinecek. Hem iOS hem de Android tarafında test edilen özelliğin herkese ne zaman açılacağı henüz tam olarak bilinmiyor.
WhatsApp, “kaybolan mesaj” altyapısına yeni bir imkan getiriyor yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.
Anthropic, geçtiğimiz hafta “Claude” için Elon Musk’ın özel uzay şirketi SpaceX ile iş birliği yaptığını duyurdu. Musk’ın yapay zeka şirketi xAI’ın da sahibi olan SpaceX’in “Colossus 1” isimli veri merkezini temel alan iş birliği hakkında şirket, “SpaceX ile yaptığımız yeni ortaklık sayesinde işlem kapasitemizi ciddi oranda artırıyoruz. Bu adım Claude Code ve Claude API kullanım limitlerini yukarı çekmemize olanak sağladı. Bugünden itibaren Claude Code’un Pro, Max ve Team planlarındaki 5 saatlik limiti iki katına çıkarıyor, Pro ve Max planlarındaki yoğun saat kısıtlamalarını kaldırıyor ve Opus modelleri için API limitlerini önemli ölçüde yükseltiyoruz. SpaceX ile vardığımız mutabakat çerçevesinde, şirketin Colossus 1 veri merkezindeki tüm kapasiteyi kullanacağız. Bu sayede 300 megavattan fazla ek kapasiteye kavuşmuş olacağız.” ifadelerini kullanmıştı. Yakında ilk operasyon kârını açıklayacağını duyuran Anthropic, bugün öğrendiğimiz kadarıyla yapılan iş birliği kapsamında Mayıs 2029’a kadar SpaceX’e aylık tam 1,25 milyar dolar ödeme yapacak. Anlaşmanın SpaceX’e toplamda 40 milyar doların üzerinde gelir getirebileceği […]
Anthropic, veri merkezi anlaşması kapsamında SpaceX’e her ay devasa bir ödeme yapacak yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.
During the last football World Cup, we built a lightweight live-score mini app focused on fast match updates, prediction games, and group discussions.
The original goal was simple:
ultra-fast score updates
low mobile bandwidth usage
stable performance during traffic spikes
minimal server costs
What surprised us was how difficult the “goal moment” problem became.
Whenever a goal happened in a knockout-stage match, traffic exploded almost instantly.
A single scoring event could trigger:
massive websocket fan-outs
notification bursts
cache invalidations
ranking recalculations
prediction settlements
social sharing spikes
The UI itself was the easy part.
The real challenge was keeping latency low while avoiding infrastructure meltdowns.
Overall Architecture
Here’s the simplified architecture we ended up using:
+------------------+
| Match Provider |
+--------+---------+
|
v
+------------------------+
| Match Event Queue |
| Kafka / Redis |
+-----------+------------+
|
+-----------------+-----------------+
| |
v v
+----------------+ +----------------+
| Score Workers | | Ranking Worker |
+--------+-------+ +--------+-------+
| |
v v
+---------------+ +----------------+
| Redis Cluster | | Prediction DB |
+-------+-------+ +----------------+
|
v
+-------------------+
| WebSocket Gateway |
+---------+---------+
|
+---------+---------+
| |
v v
+———-+ +————-+
| Mini App | | Mobile Web |
+———-+ +————-+
The core idea was:
Redis handled short-lived hot data
MySQL stored historical match data
WebSocket handled live pushes
Kafka buffered bursts during peak events
The “Goal Spike” Problem
The biggest traffic spikes happened immediately after goals.
Not during kickoff.
Not during halftime.
Only goals.
Traffic patterns looked roughly like this:
Minute 0-20 → stable
Goal event → 12x websocket burst
VAR review → reconnect storms
Penalty shootout → total chaos
We originally used polling every 5 seconds.
That completely failed during high-profile matches.
The problems:
huge duplicate requests
unnecessary database reads
delayed score updates
battery drain on mobile
We replaced polling with websocket streams plus local incremental updates.
That reduced backend request volume by around 78%.
Why Mini Apps Were Difficult
A lot of developers outside China aren’t familiar with mini app ecosystems.
The constraints are surprisingly strict.
Some examples:
limited websocket connections
package size limits
aggressive memory recycling
cold-start delays
background execution restrictions
On older Android devices, reconnect storms became a serious issue.
During penalty shootouts, some devices opened multiple duplicate websocket sessions after network jitter.
That created ghost connections which kept consuming memory on the gateway layer.
We eventually added:
heartbeat validation
duplicate-session eviction
exponential reconnect backoff
local event deduplication
That stabilized things considerably.
Redis Became the Most Important Layer
Originally we treated Redis as a secondary cache.
That was a mistake.
During peak matches, Redis effectively became the real-time backbone of the entire system.
We used it for:
live scores
match timelines
ranking snapshots
prediction counters
websocket routing
hot room metadata
One optimization that helped a lot:
Instead of invalidating large leaderboard structures after every event, we switched to partial incremental ranking updates.
That reduced ranking recomputation time from several seconds to under 200ms.
CDN Optimization Helped More Than Expected
One unexpected bottleneck was actually images.
Especially:
national flags
player avatars
emoji reactions
sticker packs
During semifinals, image bandwidth briefly exceeded websocket traffic.
We fixed this by:
aggressive WebP compression
sprite merging
edge CDN caching
lazy-loading reaction assets
Cold-start speed improved noticeably afterward.
Prediction Systems Were Surprisingly Expensive
The prediction feature looked harmless at first.
Users could guess:
final score
first goal scorer
possession rate
match winner
The problem was settlement traffic.
When matches ended, millions of prediction calculations triggered almost simultaneously.
Our first implementation recalculated rankings synchronously.
That caused database lock contention immediately.
We eventually moved settlement into async queues and chunked ranking updates into batches.
That eliminated most timeout issues.
WebSocket Fan-Out Was the Hardest Part
The most difficult engineering problem was websocket broadcasting.
A single goal event might need to reach:
live score rooms
prediction rooms
chat rooms
trending feeds
push notification workers
Naively broadcasting everything everywhere quickly became too expensive.
We switched to segmented channels:
match:arg-vs-fra
match:eng-vs-ned
prediction:global
chat:room:3821
This reduced unnecessary fan-outs significantly.
What Failed
Several things worked terribly.
Polling
Completely unsustainable during peak traffic.
Full leaderboard recalculation
Too expensive.
Large websocket payloads
Mobile packet loss became noticeable.
Synchronous push notifications
Created retry storms.
Real-time chat moderation
Much harder than expected during controversial matches.
What Worked Well
A few things scaled surprisingly well:
Redis Pub/Sub
websocket segmentation
edge caching
event queues
incremental ranking updates
local optimistic rendering
One interesting UX optimization:
We updated the score instantly on the client before the full match timeline arrived.
Users perceived the app as much faster even though backend latency stayed roughly the same.
Traffic Numbers
Some approximate peak metrics during knockout-stage matches:
Metric Peak
Concurrent websocket connections ~180k
Match event fan-outs/minute ~12M
Redis ops/sec ~500k
CDN image requests/minute ~8M
Peak websocket bandwidth ~4.2 Gbps
The infrastructure costs were still lower than we originally expected because most traffic was transient and cache-heavy.
Biggest Lesson
The biggest lesson was:
Real-time sports traffic is extremely bursty.
Most systems look stable right up until a major goal happens.
Then everything breaks simultaneously.
Designing for average traffic is almost meaningless for live sports products.
You have to design for emotional moments.
That changes everything:
traffic patterns
reconnect behavior
sharing behavior
caching strategy
notification systems
moderation workload
If We Rebuilt It Today
We would probably:
use protobuf for websocket payloads
reduce payload sizes further
move more logic to edge workers
introduce regional websocket routing
precompute ranking snapshots
use CRDT-style synchronization for chat
We’d also invest more in observability earlier.
During the first week, debugging realtime issues without proper tracing was painful.
Final Thoughts
The most interesting part of building a football live-score system wasn’t sports data.
It was understanding how human behavior changes during high-emotion events.
Goals create synchronized traffic spikes unlike almost anything else on the internet.
And penalty shootouts are basically distributed systems chaos testing.