<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://drobinin.com/posts/am-i-a-bad-friend/"/>
	<rdf:li rdf:resource="https://github.com/mautrix/whatsapp?tab=readme-ov-file"/>
	<rdf:li rdf:resource="https://rys.io/en/179.html"/>
	<rdf:li rdf:resource="https://softwaremill.com/mqperf/"/>
	<rdf:li rdf:resource="https://therecord.media/this-app-will-self-destruct-how-belarusian-hackers-created-an-alternative-telegram-for-activists/"/>
	<rdf:li rdf:resource="https://bitesizedserverless.com/bite/serverless-messaging-latency-compared/"/>
	<rdf:li rdf:resource="https://www.patrick-breyer.de/en/posts/messaging-and-chat-control/"/>
	<rdf:li rdf:resource="https://idlewords.com/talks/hk_stanford.html"/>
	<rdf:li rdf:resource="https://blog.softwaremill.com/does-kafka-really-guarantee-the-order-of-messages-3ca849fd19d2"/>
	<rdf:li rdf:resource="https://www.tuppenceworth.ie/blog/2019/06/24/why-the-bai-is-not-the-body-to-regulate-the-internet/"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=18564246"/>
	<rdf:li rdf:resource="https://segment.com/blog/exactly-once-delivery/"/>
	<rdf:li rdf:resource="http://dangrover.com/blog/2016/04/20/bots-wont-replace-apps.html"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/android-gcm/PpLBwPTe0f0/_0HtmyeVAQAJ"/>
	<rdf:li rdf:resource="https://support.google.com/googleplay/android-developer/answer/2663268"/>
	<rdf:li rdf:resource="https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you"/>
	<rdf:li rdf:resource="https://www.informatica.com/downloads/1568_high_perf_messaging_wp/Topics-in-High-Performance-Messaging.htm"/>
	<rdf:li rdf:resource="http://ingest.tips/2015/03/26/what-is-confusing-about-kafka/"/>
	<rdf:li rdf:resource="http://blog.confluent.io/2015/03/25/a-comprehensive-open-source-rest-proxy-for-kafka/"/>
	<rdf:li rdf:resource="http://www.grpc.io/"/>
	<rdf:li rdf:resource="http://fortune.com/2015/02/12/slack-growth/"/>
	<rdf:li rdf:resource="http://tech.forter.com/comparing-message-queue-architectures-on-aws/"/>
	<rdf:li rdf:resource="http://www.theguardian.com/technology/2015/jan/13/david-cameron-encrypted-messaging-apps-ban"/>
	<rdf:li rdf:resource="https://github.com/sclasen/event-shuttle"/>
	<rdf:li rdf:resource="http://brooker.co.za/blog/2014/11/15/exactly-once.html"/>
	<rdf:li rdf:resource="http://gotocon.com/dl/goto-berlin-2014/slides/MartinThompson_AeronTheNextGenerationInOpenSourceHighPerformanceMessaging.pdf"/>
	<rdf:li rdf:resource="http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/"/>
	<rdf:li rdf:resource="https://projects.eclipse.org/proposals/moquette-mqtt"/>
	<rdf:li rdf:resource="http://adampash.com/imessage-purgatory/"/>
	<rdf:li rdf:resource="http://mechanical-sympathy.blogspot.co.uk/2014/05/simple-binary-encoding.html"/>
	<rdf:li rdf:resource="http://yahooeng.tumblr.com/post/64758709722/making-storm-fly-with-netty"/>
	<rdf:li rdf:resource="https://github.com/peter-lawrey/Java-Chronicle"/>
	<rdf:li rdf:resource="http://developer.android.com/google/gcm/index.html"/>
	<rdf:li rdf:resource="http://www.infoq.com/interviews/ennis-events"/>
	<rdf:li rdf:resource="http://kentonv.github.com/capnproto/"/>
	<rdf:li rdf:resource="https://pushover.net/"/>
	<rdf:li rdf:resource="http://incubator.apache.org/kafka/index.html"/>
	<rdf:li rdf:resource="http://perspectives.mvdirona.com/2011/10/25/StorageInfrastructureBehindFacebookMessages.aspx"/>
	<rdf:li rdf:resource="http://dashes.com/anil/2009/07/the-pushbutton-web-realtime-becomes-real.html"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://drobinin.com/posts/am-i-a-bad-friend/">
    <title>1.2M Messages to Obsidian - Building a Relationship Map from 20 Years of Chat History</title>
    <dc:date>2026-05-28T13:08:36+00:00</dc:date>
    <link>https://drobinin.com/posts/am-i-a-bad-friend/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Am I a bad friend?" -- Vadim Drobinin "analysed 20 years of my chats and turned 1.2M messages into a structured vault of my life - to win friends and influence people. Instead, I learnt things about my emotional bandwidth, endearment cycles, and friendship half-lives."

This is actually a really nice project. I wish I'd accumulated and archived all that data over the years myself to do something similar.]]></description>
<dc:subject>dataviz analysis friendship life relationships vocabulary words text dunbar-number chats group-chats messaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:62c07505c935/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataviz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:friendship"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:life"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:relationships"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vocabulary"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:words"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:text"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dunbar-number"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:group-chats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/mautrix/whatsapp?tab=readme-ov-file">
    <title>GitHub - mautrix/whatsapp: A Matrix-WhatsApp puppeting bridge</title>
    <dc:date>2026-03-23T11:11:10+00:00</dc:date>
    <link>https://github.com/mautrix/whatsapp?tab=readme-ov-file</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I've been investigating how I can back up my WhatsApp chat history and make it searchable (since WhatsApp's own built in search is not great).  Turns out you can bridge WhatsApp into Matrix, and gateway your chats over to a self-hosted Matrix.org server.  https://github.com/osteele/matrix-archive may then be a viable way to export those into a searchable format... or possibly this one? https://github.com/cameronaaron/matrix-archive/tree/master]]></description>
<dc:subject>matrix whatsapp messaging chat interop searching self-hosted</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:014855f8a243/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:matrix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:whatsapp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:searching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:self-hosted"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://rys.io/en/179.html">
    <title>Telegram is indistinguishable from an FSB honeypot</title>
    <dc:date>2025-06-10T14:04:49+00:00</dc:date>
    <link>https://rys.io/en/179.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is not great -- prepending a cleartext device ID string alone is a very fishy decision]]></description>
<dc:subject>encryption security infosec telegram messaging mtproto</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f4cead6bdbcc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:telegram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mtproto"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://softwaremill.com/mqperf/">
    <title>Evaluating persistent, replicated message queues</title>
    <dc:date>2024-08-26T09:47:38+00:00</dc:date>
    <link>https://softwaremill.com/mqperf/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is exhaustive!

Kafka, Postgres, mongodb, Redis, Pulsar, SQS, EventStore, RocketMQ, RabbitMQ, ActiveMQ, and RedPanda all compared as backends for a persistent, replicated message queueing system.  SQS actually fares quite well
]]></description>
<dc:subject>activemq kafka rabbitmq messaging queueing message-queues sqs postgres storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d187c123119b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:activemq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rabbitmq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:message-queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgres"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://therecord.media/this-app-will-self-destruct-how-belarusian-hackers-created-an-alternative-telegram-for-activists/">
    <title>This app will self-destruct: How Belarusian hackers created an alternative Telegram</title>
    <dc:date>2023-01-11T17:57:14+00:00</dc:date>
    <link>https://therecord.media/this-app-will-self-destruct-how-belarusian-hackers-created-an-alternative-telegram-for-activists/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great idea:

<blockquote>
When a 25-year-old activist from Minsk who goes by Pavlo was detained by Belarusian KGB security forces last summer, he knew they would search his phone, looking for evidence of his involvement in anti-government protests. 

The police officer asked for Pavlo’s password to Telegram, the most popular messenger app among Belarusian activists, which he gave him. The officer entered it and... found nothing. All secret chats and news channels had disappeared, and after a few minutes of questioning Pavlo was released. 

Pavlo’s secret? A secure version of Telegram, developed by a hacktivist group from Belarus called the Cyber Partisans. Partisan Telegram, or P-Telegram, automatically deletes pre-selected chats when someone enters the so-called SOS password.
</blockquote>

<blockquote>
... after entering a fake [SOS] password, P-Telegram can automatically log out of the account, delete selected chats and channels, and even send a notification about the arrest of the account owners to their friends or families.

P-Telegram also allows other activists to remotely activate the SOS password on the detainee’s phone. For this, they need to send a code word to any of the shared Telegram chats.

Another feature on P-Telegram automatically takes photos of law enforcement officers on the front camera when they enter a fake password. “We warn users that this can be dangerous, as this photo will be stored on the phone, revealing that a person may use Partisan Telegram,” Shemetovets said. 

Cyber Partisans are constantly updating their app, fixing bugs, and adding new features. They also regularly conduct independent audits to ensure that P-Telegram complies with all security measures.

A recent audit by Open Technology Fund’s Red Team Lab proved that it is almost impossible for “casual observers without technical knowledge and specialized equipment” to identify the existence of P-Telegram on a device.</blockquote>

]]></description>
<dc:subject>p-telegram hacktivism security telegram messaging privacy activism duress-passwords</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fb64152bf54b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:p-telegram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacktivism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:telegram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:activism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:duress-passwords"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://bitesizedserverless.com/bite/serverless-messaging-latency-compared/">
    <title>Serverless Messaging: Latency Compared</title>
    <dc:date>2022-09-07T08:46:07+00:00</dc:date>
    <link>https://bitesizedserverless.com/bite/serverless-messaging-latency-compared/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Various AWS queueing/messaging services' latencies compared in eu-west-1:

'When latency matters, there are a few obvious winners. SQS Standard can deliver a message to a consumer in as fast as 14 ms and is seldomly slower than 100 ms, assuming low batch sizes. Kinesis with Enhanced Fan-Out is only slightly slower and allows for multiple consumers and a long history of events. SNS falls in the low latency category too, although the SNS FIFO option includes more moving parts and thus a larger latency spread, up to half a second.
Step Functions and DynamoDB Streams take up the middle section, with P50 latencies up to about 200 ms.
The highest latency is introduced by EventBridge and Kinesis Data Streams without Enhanced Fan-Out. These services add at least a few hundred milliseconds to your integrations, but can easily run up to a second or more.']]></description>
<dc:subject>aws latency messaging queues architecture ops sqs sns kinesis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0fd2c91e94ef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kinesis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.patrick-breyer.de/en/posts/messaging-and-chat-control/">
    <title>Chat Control</title>
    <dc:date>2022-05-13T09:50:56+00:00</dc:date>
    <link>https://www.patrick-breyer.de/en/posts/messaging-and-chat-control/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["The End of the Privacy of Digital Correspondence":

<blockquote>
The EU wants to oblige providers to search all private chats, messages, and emails automatically for suspicious content – generally and indiscriminately. The stated aim: To prosecute child pornography. The result: Mass surveillance by means of fully automated real-time messaging and chat control and the end of secrecy of digital correspondence.

Other consequences of the proposal are ineffective network blocking, screening of person cloud storage including private photos, mandatory age verification leading to the end of anonymous communication, censorship in Appstores and the paternalism and exclusion of minors in the digital world.
</blockquote>]]></description>
<dc:subject>surveillance censorship chat-control eu laws messaging apps privacy data-privacy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:133f804a604c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:surveillance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:censorship"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chat-control"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:laws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-privacy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://idlewords.com/talks/hk_stanford.html">
    <title>Observations on Technology Use in Hong Kong Protests</title>
    <dc:date>2019-09-19T16:12:46+00:00</dc:date>
    <link>https://idlewords.com/talks/hk_stanford.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Very interesting. Good to see Telegram in the app list:

'Telegram is the preferred messenger app among protesters. It’s used for one-on-one messaging between people, among small groups of people to coordinate, and among very large groups to amplify and disseminate information. The polls feature in Telegram is also a way of affirming consensus in group decision making. Several features of Telegram make it attractive to protesters:

Disappearing messages. If the police force you to unlock your phone, you don’t give up your friends.

Groups with very large membership (tens of thousands, or even a hundred thousand members). This allows for quick, rapid amplification of news.

Built-in polls. Since the protest is decentralized, some mechanism is needed for decisionmaking. 
Polls in practice are used to ratify decisions where a consensus has become clear.
Ease of use.']]></description>
<dc:subject>china communication hong-kong protests protesting privacy telegram future messaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d171a80f0dd1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:china"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:communication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hong-kong"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protests"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:telegram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:future"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.softwaremill.com/does-kafka-really-guarantee-the-order-of-messages-3ca849fd19d2">
    <title>Does Kafka really guarantee the order of messages? - SoftwareMill Tech Blog</title>
    <dc:date>2019-08-29T10:44:41+00:00</dc:date>
    <link>https://blog.softwaremill.com/does-kafka-really-guarantee-the-order-of-messages-3ca849fd19d2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[tl;dr: nope --

<blockquote>It is worth to know that default configuration can lead to producing messages in the wrong order when a failure happens, and if message order is important for your application you can have a lot of trouble because someone told you about the guarantees that as you can see are not always true.</blockquote>

]]></description>
<dc:subject>messaging kafka streaming ordering exactly-once distcomp events</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:021230249496/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ordering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exactly-once"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:events"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.tuppenceworth.ie/blog/2019/06/24/why-the-bai-is-not-the-body-to-regulate-the-internet/">
    <title>Why the BAI is not the body to regulate the internet</title>
    <dc:date>2019-06-24T13:35:15+00:00</dc:date>
    <link>https://www.tuppenceworth.ie/blog/2019/06/24/why-the-bai-is-not-the-body-to-regulate-the-internet/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Simon McGarr makes a good argument, and I agree]]></description>
<dc:subject>bai ireland regulation internet web messaging crypto privacy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:57a707f19abe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=18564246">
    <title>PRDD - Performance-Review Driven Development</title>
    <dc:date>2018-11-30T14:41:01+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=18564246</link>
    <dc:creator>jm</dc:creator><description><![CDATA['If the way to get promoted is to launch a shiny new product, then your most senior people will be the best at finding shiny new products to launch, even if that's not the right technical decision to make.'  (from a newsy thread about Twitter's latest messaging system switch)]]></description>
<dc:subject>newsy messaging infrastructure twitter kafka pubsub ops architecture prdd performance-reviews</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6a5adfb4891c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:newsy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infrastructure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pubsub"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prdd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance-reviews"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://segment.com/blog/exactly-once-delivery/">
    <title>Delivering Billions of Messages Exactly Once · Segment Blog</title>
    <dc:date>2017-06-30T14:59:58+00:00</dc:date>
    <link>https://segment.com/blog/exactly-once-delivery/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[holy crap, this is exactly the wrong way to build a massive-scale deduplication system -- with a monster random-access "is this random UUID in the db" lookup]]></description>
<dc:subject>deduping architecture horror segment messaging kafka</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6ed4de95c0f3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deduping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:horror"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:segment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dangrover.com/blog/2016/04/20/bots-wont-replace-apps.html">
    <title>Bots won't replace apps. Better apps will replace apps</title>
    <dc:date>2016-04-25T12:10:03+00:00</dc:date>
    <link>http://dangrover.com/blog/2016/04/20/bots-wont-replace-apps.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>As I’ll explain, messenger apps’ apparent success in fulfilling such a surprising array of tasks does not owe to the triumph of “conversational UI.” What they’ve achieved can be much more instructively framed as an adept exploitation of Silicon Valley phone OS makers’ growing failure to fully serve users’ needs, particularly in other parts of the world. Chat apps have responded by evolving into “meta-platforms.” Many of the platform-like aspects they’ve taken on to plaster over gaps in the OS actually have little to do with the core chat functionality. Not only is “conversational UI” a red herring, but as we look more closely, we’ll even see places where conversational UI has breached its limits and broken down.</blockquote>

]]></description>
<dc:subject>apps bots chatops chat ui messaging silicon-valley agents alexa siri phones</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:158a4abdfa4d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bots"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chatops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:silicon-valley"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alexa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:siri"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phones"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/android-gcm/PpLBwPTe0f0/_0HtmyeVAQAJ">
    <title>GCM XMPP delivery receipt not always received - Google Groups</title>
    <dc:date>2016-03-18T10:06:43+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/android-gcm/PpLBwPTe0f0/_0HtmyeVAQAJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good to know:<blockquote>'GCM delivery receipts don't have an SLA at this time. Having your connection open longer will increase the odds that delivery receipts will arrive. 10 seconds seems a bit short. I'm glad it works. I would recommend longer like 10 min or an hour. The real design of this system is for persistent connections, hence connections that setup and tear down frequently will have difficulty receiving delivery receipts.'</blockquote>

]]></description>
<dc:subject>gcm xmpp receipts messaging push-notifications google</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0c54a2280d4e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xmpp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:receipts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push-notifications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://support.google.com/googleplay/android-developer/answer/2663268">
    <title>View &amp; diagnose Google Cloud Messaging (GCM) statistics</title>
    <dc:date>2016-02-08T13:11:56+00:00</dc:date>
    <link>https://support.google.com/googleplay/android-developer/answer/2663268</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Looks like GCM now offers a way to determine if a message got delivered, via the GCM diagnostics console]]></description>
<dc:subject>gcm google push-notifications android messaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:12c185dbe30f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push-notifications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you">
    <title>5 subtle ways you're using MySQL as a queue, and why it'll bite you</title>
    <dc:date>2016-01-06T12:42:41+00:00</dc:date>
    <link>https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent post from Percona. I particularly like that they don't just say "don't use MySQL" -- they give good advice on how it can be made work: 1) avoid polling; 2) avoid locking; and 3) avoid storing your queue in the same table as other data.]]></description>
<dc:subject>database mysql queueing queue messaging percona rds locking sql architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5081114f1b88/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.informatica.com/downloads/1568_high_perf_messaging_wp/Topics-in-High-Performance-Messaging.htm">
    <title>Topics in High-Performance Messaging</title>
    <dc:date>2015-12-02T15:53:00+00:00</dc:date>
    <link>https://www.informatica.com/downloads/1568_high_perf_messaging_wp/Topics-in-High-Performance-Messaging.htm</link>
    <dc:creator>jm</dc:creator><description><![CDATA['We have worked together in the field of high-performance messaging for many years, and in that time, have seen some messaging systems that worked well and some that didn't. Successful deployment of a messaging system requires background information that is not easily available; most of what we know, we had to learn in the school of hard knocks. To save others a knock or two, we have collected here the essential background information and commentary on some of the issues involved in successful deployments. This information is organized as a series of topics around which there seems to be confusion or uncertainty. Please contact us if you have questions or comments.']]></description>
<dc:subject>messaging scalability scaling performance udp tcp protocols multicast latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aef1848d9376/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multicast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ingest.tips/2015/03/26/what-is-confusing-about-kafka/">
    <title>What's confusing about Kafka: a list</title>
    <dc:date>2015-03-26T10:03:20+00:00</dc:date>
    <link>http://ingest.tips/2015/03/26/what-is-confusing-about-kafka/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>At a recent call, Neha said “The most confusing behavior we have is how producing to a topic can return errors for few seconds after the topic was already created”. As she said that, I remembered that indeed, this was once very confusing, but then I got used to it.  Which got us thinking: What other things that Kafka does are very confusing to new users, but we got so used to them that we no longer even see the issue?</blockquote>

]]></description>
<dc:subject>kafka messaging tips gotchas</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8b177564215c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gotchas"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.confluent.io/2015/03/25/a-comprehensive-open-source-rest-proxy-for-kafka/">
    <title>The official REST Proxy for Kafka</title>
    <dc:date>2015-03-25T22:08:12+00:00</dc:date>
    <link>http://blog.confluent.io/2015/03/25/a-comprehensive-open-source-rest-proxy-for-kafka/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The REST Proxy is an open source HTTP-based proxy for your Kafka cluster. The API supports many interactions with your cluster, including producing and consuming messages and accessing cluster metadata such as the set of topics and mapping of partitions to brokers. Just as with Kafka, it can work with arbitrary binary data, but also includes first-class support for Avro and integrates well with Confluent’s Schema Registry. And it is scalable, designed to be deployed in clusters and work with a variety of load balancing solutions.

We built the REST Proxy first and foremost to meet the growing demands of many organizations that want to use Kafka, but also want more freedom to select languages beyond those for which stable native clients exist today. However, it also includes functionality beyond traditional clients, making it useful for building tools for managing your Kafka cluster. See the documentation for a more detailed description of the included features.</blockquote>

]]></description>
<dc:subject>kafka rest proxies http confluent queues messaging streams architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4c70bf63df1b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proxies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:confluent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.grpc.io/">
    <title>grpc.io</title>
    <dc:date>2015-02-26T22:13:53+00:00</dc:date>
    <link>http://www.grpc.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Binary message marshalling, client/server stubs generated by an IDL compiler, bidirectional binary protocol. CORBA is back from the dead!
Intro blog post: http://googledevelopers.blogspot.ie/2015/02/introducing-grpc-new-open-source-http2.html

Relevant: Steve Vinoski's commentary on protobuf-rpc back in 2008: http://steve.vinoski.net/blog/2008/07/13/protocol-buffers-leaky-rpc/]]></description>
<dc:subject>http rpc http2 netty grpc google corba idl messaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1a7c21fdee97/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:corba"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:idl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://fortune.com/2015/02/12/slack-growth/">
    <title>Slack's coming to Dublin</title>
    <dc:date>2015-02-13T10:19:56+00:00</dc:date>
    <link>http://fortune.com/2015/02/12/slack-growth/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Butterfield insists that Slack improves on the basic messaging functionality offered by its predecessors. The company plans to expand from 100 employees to 250 this year, open an office in Dublin, and launch a version that supports large companies with multiple teams.</blockquote>

]]></description>
<dc:subject>slack messaging chat dublin ireland jobs tech</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2cdb57df5e3e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slack"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jobs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tech"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.forter.com/comparing-message-queue-architectures-on-aws/">
    <title>Comparing Message Queue Architectures on AWS</title>
    <dc:date>2015-02-03T00:40:40+00:00</dc:date>
    <link>http://tech.forter.com/comparing-message-queue-architectures-on-aws/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A good overview -- I like the summary table.  tl;dr: <blockquote>If you are light on DevOps and not latency sensitive use SQS for job management and Kinesis for event stream processing. If latency is an issue, use ELB or 2 RabbitMQs (or 2 beanstalkds) for job management and Redis for event stream processing.</blockquote>

]]></description>
<dc:subject>amazon architecture aws messaging queueing elb rabbitmq beanstalk kinesis sqs redis kafka</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ae3870806c75/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rabbitmq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:beanstalk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kinesis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.theguardian.com/technology/2015/jan/13/david-cameron-encrypted-messaging-apps-ban">
    <title>David Cameron in 'cloud cuckoo land' over encrypted messaging apps ban | Technology | The Guardian</title>
    <dc:date>2015-01-13T22:17:07+00:00</dc:date>
    <link>http://www.theguardian.com/technology/2015/jan/13/david-cameron-encrypted-messaging-apps-ban</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>One insider at a major US technology firm told the Guardian that “politicians are fond of asking why it is that tech companies don’t base themselves in the UK” ... “I think if you’re saying that encryption is the problem, at a time when consumers and businesses see encryption as a very necessary part of trust online, that’s a very indicative point of view.”</blockquote>

]]></description>
<dc:subject>business guardian david-cameron uk-politics crypto ripa messaging internet privacy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d4b2d0bade68/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:guardian"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:david-cameron"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uk-politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ripa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/sclasen/event-shuttle">
    <title>sclasen/event-shuttle</title>
    <dc:date>2014-11-25T12:06:52+00:00</dc:date>
    <link>https://github.com/sclasen/event-shuttle</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>UNIX system service [jmason: ie a sidecar] that collects events and reliably delivers them to kafka, relieving other services on the same system from having to do so.  Journals events through bolt-db so that in the event of an kafka outage, events can still be accepted, and will be delivered when kafka becomes available.</blockquote>

]]></description>
<dc:subject>kafka messaging ruby go events fault-tolerance queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:58fdafc74a8c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:events"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://brooker.co.za/blog/2014/11/15/exactly-once.html">
    <title>Exactly-Once Delivery May Not Be What You Want</title>
    <dc:date>2014-11-19T10:29:06+00:00</dc:date>
    <link>http://brooker.co.za/blog/2014/11/15/exactly-once.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An extremely good explanation from Marc Brooker that exactly-once delivery in a distributed system is very hard.

<blockquote>And so on. There's always a place to slot in one more turtle. The bad news is that I'm not aware of a nice solution to the general problem for all side effects, and I suspect that no such solution exists. On the bright side, there are some very nice solutions that work really well in practice. The simplest is idempotence. This is a very simple idea: we make the tasks have the same effect no matter how many times they are executed.</blockquote>

]]></description>
<dc:subject>architecture messaging queues exactly-once-delivery reliability fault-tolerance distcomp marc-brooker</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bd33fabfecec/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exactly-once-delivery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:marc-brooker"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://gotocon.com/dl/goto-berlin-2014/slides/MartinThompson_AeronTheNextGenerationInOpenSourceHighPerformanceMessaging.pdf">
    <title>&quot;Aeron: High-Performance Open Source Message Transport&quot; [slides, PDF]</title>
    <dc:date>2014-11-12T10:08:56+00:00</dc:date>
    <link>http://gotocon.com/dl/goto-berlin-2014/slides/MartinThompson_AeronTheNextGenerationInOpenSourceHighPerformanceMessaging.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a new networked pub/sub library from Martin "Disruptor" Thompson, based around a replicated, persistent log of messages, with exceptionally low latency.  Apache-licensed.  Very similar to the realtime messaging stack we've built in Swrve. ;)

https://github.com/real-logic/Aeron]]></description>
<dc:subject>realtime messaging pub-sub ipc queues transports martin-thompson slides latencies open-source java libraries</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:63cce56da5d7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pub-sub"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:transports"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:martin-thompson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/">
    <title>The Saga pattern</title>
    <dc:date>2014-10-01T14:01:14+00:00</dc:date>
    <link>http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a distribution of long-living [distributed] transactions where steps may interleave, each with associated compensating transactions providing a compensation path across databases in the occurrence of a fault that may or may not compensate the entire chain back to the originator.']]></description>
<dc:subject>distributed messaging saga patterns architecture transactions distributed-transactions distcomp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1e75f48db4f6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:saga"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:transactions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-transactions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://projects.eclipse.org/proposals/moquette-mqtt">
    <title>Moquette MQTT</title>
    <dc:date>2014-05-29T15:35:02+00:00</dc:date>
    <link>https://projects.eclipse.org/proposals/moquette-mqtt</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a Java implementation of an MQTT 3.1 broker. Its code base is small. At its core, Moquette is an events processor; this lets the code base be simple, avoiding thread sharing issues. The Moquette broker is lightweight and easy to understand so it could be embedded in other projects.</blockquote>

]]></description>
<dc:subject>mqtt moquette netty messaging queueing push-notifications iot internet push eclipse</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:258866cdaffb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mqtt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:moquette"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push-notifications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eclipse"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://adampash.com/imessage-purgatory/">
    <title>iMessage purgatory</title>
    <dc:date>2014-05-14T16:23:07+00:00</dc:date>
    <link>http://adampash.com/imessage-purgatory/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Oh Apple, you asshats. This is some seriously shitty programming.  iMessage on iOS devices caches the "iMessage-capable" flag for all numbers, indefinitely, so if you switch from iPhone to Android, messages from your friends' iPhones won't get delivered to you henceforth -- and to add insult to injury, it claims they do with a "Delivered." status appearing under the message.  This is happening to me right now...]]></description>
<dc:subject>apple sms messaging phones mobile imessage android fail bad-programming bugs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4ea4d281d586/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phones"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:imessage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bad-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mechanical-sympathy.blogspot.co.uk/2014/05/simple-binary-encoding.html">
    <title>Simple Binary Encoding</title>
    <dc:date>2014-05-06T14:31:54+00:00</dc:date>
    <link>http://mechanical-sympathy.blogspot.co.uk/2014/05/simple-binary-encoding.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>an OSI layer 6 presentation for encoding/decoding messages in binary format to support low-latency applications.  [...] SBE follows a number of design principles to achieve this goal. By adhering to these design principles sometimes means features available in other codecs will not being offered. For example, many codecs allow strings to be encoded at any field position in a message; SBE only allows variable length fields, such as strings, as fields grouped at the end of a message.

The SBE reference implementation consists of a compiler that takes a message schema as input and then generates language specific stubs. The stubs are used to directly encode and decode messages from buffers. The SBE tool can also generate a binary representation of the schema that can be used for the on-the-fly decoding of messages in a dynamic environment, such as for a log viewer or network sniffer.

The design principles drive the implementation of a codec that ensures messages are streamed through memory without backtracking, copying, or unnecessary allocation. Memory access patterns should not be underestimated in the design of a high-performance application. Low-latency systems in any language especially need to consider all allocation to avoid the resulting issues in reclamation. This applies for both managed runtime and native languages. SBE is totally allocation free in all three language implementations.

The end result of applying these design principles is a codec that has ~25X greater throughput than Google Protocol Buffers (GPB) with very low and predictable latency. This has been observed in micro-benchmarks and real-world application use. A typical market data message can be encoded, or decoded, in ~25ns compared to ~1000ns for the same message with GPB on the same hardware. XML and FIX tag value messages are orders of magnitude slower again.

The sweet spot for SBE is as a codec for structured data that is mostly fixed size fields which are numbers, bitsets, enums, and arrays. While it does work for strings and blobs, many my find some of the restrictions a usability issue. These users would be better off with another codec more suited to string encoding.</blockquote>

]]></description>
<dc:subject>sbe encoding protobuf protocol-buffers json messages messaging binary formats low-latency martin-thompson xml</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bac9f09a3e68/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sbe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encoding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protobuf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocol-buffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:binary"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:formats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:martin-thompson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xml"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://yahooeng.tumblr.com/post/64758709722/making-storm-fly-with-netty">
    <title>Making Storm fly with Netty | Yahoo Engineering</title>
    <dc:date>2013-10-23T21:09:21+00:00</dc:date>
    <link>http://yahooeng.tumblr.com/post/64758709722/making-storm-fly-with-netty</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Y! engineer doubles the speed of Storm's messaging layer by replacing the zeromq implementation with Netty]]></description>
<dc:subject>netty async zeromq storm messaging tcp benchmarks yahoo clusters</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0980d14db16f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zeromq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yahoo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clusters"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/peter-lawrey/Java-Chronicle">
    <title>Chronicle</title>
    <dc:date>2013-07-20T22:49:52+00:00</dc:date>
    <link>https://github.com/peter-lawrey/Java-Chronicle</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>an ultra low latency, high throughput, persisted, messaging and event driven in memory database. The typical latency is as low as 80 nano-seconds and supports throughputs of 5-20 million messages/record updates per second.

This library also supports distributed, durable, observable collections (Map, List, Set) The performance depends on the data structures used, but simple data structures can achieve throughputs of 5 million elements or key/value pairs in batches (eg addAll or putAll) and 500K elements or key/values per second when added/updated/removed individually.

It uses almost no heap, trivial GC impact, can be much larger than your physical memory size (only limited by the size of your disk) and can be shared between processes with better than 1/10th latency of using Sockets over loopback. It can change the way you design your system because it allows you to have independent processes which can be running or not at the same time (as no messages are lost) This is useful for restarting services and testing your services from canned data. e.g. like sub-microsecond durable messaging. You can attach any number of readers, including tools to see the exact state of the data externally.</blockquote>

]]></description>
<dc:subject>library messaging performance java chronicle disk mmap</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0ab1167f9448/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:library"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chronicle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mmap"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://developer.android.com/google/gcm/index.html">
    <title>Google Cloud Messaging for Android</title>
    <dc:date>2013-07-02T21:20:22+00:00</dc:date>
    <link>http://developer.android.com/google/gcm/index.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>GCM is a service that allows you to send data from your server to your users' Android-powered device, and also to receive messages from devices on the same connection. The GCM service handles all aspects of queueing of messages and delivery to the target Android application running on the target device. GCM is completely free no matter how big your messaging needs are, and there are no quotas.</blockquote>

]]></description>
<dc:subject>gcm messaging android google push</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1031ad3a1e48/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/interviews/ennis-events">
    <title>Darach Ennis on CEP, Stream Processing, Messaging, OOP vs Functional Architecture</title>
    <dc:date>2013-05-14T21:03:27+00:00</dc:date>
    <link>http://www.infoq.com/interviews/ennis-events</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good interview -- lots of food for thought!]]></description>
<dc:subject>darach-ennis stream-processing messaging architecture qcon interviews erlang cep realtime rx comet events</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:262333000223/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:darach-ennis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stream-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qcon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cep"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:events"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://kentonv.github.com/capnproto/">
    <title>Cap'n Proto</title>
    <dc:date>2013-04-03T16:22:04+00:00</dc:date>
    <link>http://kentonv.github.com/capnproto/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Cap’n Proto is an insanely fast data interchange format and capability-based RPC system. Think JSON, except binary. Or think Protocol Buffers, except faster. In fact, in benchmarks, Cap’n Proto is INFINITY TIMES faster than Protocol Buffers.</blockquote>

Basically, marshalling like writing an aligned C struct to the wire, QNX messaging protocol-style.  Wasteful on space, but responds to this by suggesting compression (which is a fair point tbh).   C++-only for now.  I'm not seeing the same kind of support for optional data that protobufs has though.  Overall I'm worried there's some useful features being omitted here...]]></description>
<dc:subject>serialization formats protobufs capn-proto protocols coding c++ rpc qnx messaging compression compatibility interoperability i14y</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:63b8402f4508/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:serialization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:formats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protobufs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capn-proto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qnx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compatibility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interoperability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:i14y"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pushover.net/">
    <title>Pushover: Simple Mobile Notifications for Android and iOS</title>
    <dc:date>2013-01-10T11:42:55+00:00</dc:date>
    <link>https://pushover.net/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Pushover makes it easy to send real-time notifications to your Android and iOS devices.' extremely simple HTTPS API; 'Pushover has no monthly subscription fees and users will always be able to receive unlimited messages for free. Most applications can send messages for free, subject to monthly limits.'  Also supported by ifttt.com]]></description>
<dc:subject>ios android iphone push messaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:375cf4cafd42/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iphone"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://incubator.apache.org/kafka/index.html">
    <title>Apache Kafka</title>
    <dc:date>2012-02-12T00:59:16+00:00</dc:date>
    <link>http://incubator.apache.org/kafka/index.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Kafka provides a publish-subscribe solution that can handle all activity stream data and processing on a consumer-scale web site. This kind of activity (page views, searches, and other user actions) are a key ingredient in many of the social feature on the modern web. This data is typically handled by "logging" and ad hoc log aggregation solutions due to the throughput requirements. This kind of ad hoc solution is a viable solution to providing logging data to an offline analysis system like Hadoop, but is very limiting for building real-time processing. Kafka aims to unify offline and online processing by providing a mechanism for parallel load into Hadoop as well as the ability to partition real-time consumption over a cluster of machines.'  neat
]]></description>
<dc:subject>kafka linkedin apache distributed messaging pubsub queue incubator scaling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:92e2d30f6bea/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pubsub"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:incubator"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://perspectives.mvdirona.com/2011/10/25/StorageInfrastructureBehindFacebookMessages.aspx">
    <title>Storage Infrastructure Behind Facebook Messages</title>
    <dc:date>2011-10-25T22:35:16+00:00</dc:date>
    <link>http://perspectives.mvdirona.com/2011/10/25/StorageInfrastructureBehindFacebookMessages.aspx</link>
    <dc:creator>jm</dc:creator><description><![CDATA[HBase and Haystack; all data LZO-compressed; very interesting approach to testing -- they 'shadow the real production workload into the test cluster to test before going into production'. This catches a 'high percentage' of issues before production.  nice]]></description>
<dc:subject>testing shadowing haystack hbase facebook scalability lzo messaging sms via:james-hamilton</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ad64e79b1478/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shadowing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:haystack"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hbase"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lzo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:james-hamilton"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://dashes.com/anil/2009/07/the-pushbutton-web-realtime-becomes-real.html">
    <title>The Pushbutton Web: Realtime Becomes Real</title>
    <dc:date>2009-07-24T15:48:47+00:00</dc:date>
    <link>http://dashes.com/anil/2009/07/the-pushbutton-web-realtime-becomes-real.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good wrap-up from Anil Dash on "the new push"]]></description>
<dc:subject>http-push http feeds atom ping standards messaging pubsubhubbub pubsub async comet realtime web</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:470f67ac4575/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http-push"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:feeds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atom"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pubsubhubbub"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pubsub"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>