too much sweat, just SPY and chill.
david noah bocorin obrolan bareng bos sekuritas dan pengelola dana soal kondisi riil pasar saham saat ini
> bursa kita fix 85 sampai 90 persen standalone
> kenaikan indeks belakangan cuma pantulan teknikal jenuh jual dan dorongan beli danantara semata yang belum jelas bakal tahan berapa lama
> likuiditas lagi seret parah, kalo dipaksain trading di saham yang sama ujungnya malah saling sikut sesama pemodal lokal
> doi wanti-wanti mending minggir dulu nonton dari pinggir lapangan dan amankan cash, jangan sampe peluru keburu habis sebelum uptrend datang
Just write a code about rate-limiter from scratch while learning about Concurrency in Go.
decided to use Token Bucket just because it's more used by the industry.
ini namanya bukan contribute ke open-source community mas, ini sih lu fork repository orang terus lu ganti namanya dengan nama produk lu sendiri.
kalo nimpa dipikir mas @raymondchins
pasti prompt AI nya kurang lebih kek gini:
"tolong fork repository ini lalu ganti dengan nama Bridge play, make no mistake"
rebrand the app loh ya 🤣.
lain kali git commit nya dicek dulu.
github.com/raymondchins/Brid…
Migrasi ke Go aja semua makanya.
Magistra Apta retweeted
10 more books I can't recommend enough:
On your way to Software Architect (Part 2)
Here's the order I'd read them in again 👇
𝟭. 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀 𝗼𝗳 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 (Mark Richards, Neal Ford)
↳ The map of architecture styles and the "-ilities" behind them.
↳ First law: everything in software architecture is a trade-off.
𝟮. 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀 𝗼𝗳 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 (Martin Fowler)
↳ The reference for problems you hit in almost every app.
↳ After it, you'll spot these patterns in code you own.
𝟯. 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀 𝗶𝗻 .𝗡𝗘𝗧 (Trevoir Williams)
↳ Saga, CQRS, and API Gateway in real .NET code.
↳ The new edition is updated for .NET 10 and C# 14.
𝟰. 𝗗𝗼𝗺𝗮𝗶𝗻-𝗗𝗿𝗶𝘃𝗲𝗻 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿𝗶𝗻𝗴 (Alessandro Colla, Alberto Acerbis)
↳ How to apply DDD to the legacy monolith you already have.
↳ Step by step: from a big ball of mud to modules and microservices.
𝟱. 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 (Hugo Filipe Oliveira Rocha)
↳ The real pain of events: ordering, duplicates, eventual consistency.
↳ Shows how to keep data in sync when every service owns its own.
𝟲. 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: 𝗧𝗵𝗲 𝗛𝗮𝗿𝗱 𝗣𝗮𝗿𝘁𝘀 (Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani)
↳ How to split a system and its data when there's no best answer.
↳ Sagas, data ownership, and service size, with clear trade-off tables.
𝟳. 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄, 𝗩𝗼𝗹. 𝟭 (Alex Xu)
↳ A 4-step framework to design any system.
↳ Rate limiter, URL shortener, chat. Classic problems, clear diagrams.
𝟴. 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄, 𝗩𝗼𝗹. 𝟮 (Alex Xu, Sahn Lam)
↳ Harder cases: payment system, digital wallet, stock exchange.
↳ Worth reading even if you never plan to interview.
𝟵. 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝗶𝗻𝗴 𝗳𝗼𝗿 𝗦𝗰𝗮𝗹𝗲 (Lee Atchison)
↳ How to keep high availability as traffic and teams grow.
↳ Teaches you to measure and manage risk, not hope it away.
𝟭𝟬. 𝗦𝗶𝘁𝗲 𝗥𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 (Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy)
↳ How Google keeps huge systems running: SLOs and error budgets.
↳ Architecture doesn't end at deploy. This book starts there.
📌 𝗢𝗻𝗲 𝘁𝗶𝗽 𝗳𝗿𝗼𝗺 𝗺𝘆 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲:
Before you read about a pattern, find where your project needs it.
Books stick when you have a real problem to solve.
Which of these have you read, and which one helped you the most?
Magistra Apta retweeted
I was reading this paper on Amazon MemoryDB and just finished it. One of the things I love about reading systems papers is that you go in curious about a technology and come out appreciating the engineering decisions behind it.
Amazon MemoryDB: A Fast and Durable Memory-First Cloud Database -
dl.acm.org/doi/pdf/10.1145/3…
The question that caught my attention was this: how do you build something that takes advantage of the speed of memory without compromising on durability?
RAM is incredibly fast, but it's volatile. Building a database that is fast is one thing. Making sure it can recover from failures, preserve committed data, and remain highly available is a whole different challenge.
MemoryDB approaches this by using Redis as its in-memory engine and a separate, distributed transaction log for durability.
What I found interesting is the thinking behind the architecture. It's not just about squeezing out more performance; it's about deciding which responsibilities belong where and understanding the trade-offs that come with those decisions.
That led me to explore this AWS collection on in-memory databases, which connects some of these ideas to real-world systems:
A few resources I'm adding to my reading list:
→ Yahoo: Processing 1.3 million advertising events per second
youtube.com/watch?v=jEwrcpq2…
→ Building real-time applications with Amazon MemoryDB
youtube.com/watch?v=-3ATFRbu…
→ Samsung SmartThings and Amazon MemoryDB
youtube.com/watch?v=xQL31uZ7…
→ Amazon ElastiCache learning resources
pages.awscloud.com/GLB-WBNR-…
Here's the full AWS roundup that brought these resources together:
aws.amazon.com/blogs/archite…
I always find it worthwhile to read the paper first and then look at how the ideas translate into actual systems. The theory becomes much more interesting when you start thinking about the failures, workloads, and constraints engineers have to deal with in production.
If you're interested in databases or distributed systems, I'd recommend giving the paper a read. It's a good reminder that some of the most interesting engineering work happens in the decisions users never see.
#DistributedSystems #Databases #SystemDesign #AWS
Magistra Apta retweeted
What does good system design actually look like?
A great read by @sjgoedecke
seangoedecke.com/good-system…



















