Yes, it's simply a recurring phrase in the title of several papers, starting from a couple in the 70s, in which Sussman and Steele demonstrate the use of lambda calculus for programming, by means of a minimalist Lisp dialect named "Scheme" they devised for the purpose. You can find the papers themselves here; they're interesting and surprisingly relevant.
I'm not sure if this is ever explicitly stated, but it's clear (from context, having read the papers, and knowing the general background and research interests of the authors) that the phrase is simply a catchy slogan for their contention that lambda abstractions, as a computational primitive, are not only universal in the formal sense (of being able to encode any program in some fashion, however awkward), but universal in a practical sense that any and every construct present in other languages, even those that are baked-in from the ground up, can be reimplemented in a lambda-based language in a way that is both effective and natural to use.
The repeated phrase leads to the obvious generalized form "for all X, lambda is the ultimate X", which is the sense I've generally taken "Lambda the Ultimate" to mean as the blog name, noting that LtU is concerned with programming language design and theory. Ironically, LtU would probably also be one of the best places to find someone who could tell you about something for which lambda is not the ultimate implementation. :]
Note also that Sussman is one of the authors of SICP, a very influential textbook that also uses the Scheme language and spends a fair amount of time introducing lambda abstractions as a concept.
A teardown report is a summary of disassembling a product.
From Wikipedia:
A product teardown, or simply teardown, is the act of disassembling a
product, such as a television set, to identify its component parts and
functions. For products having secret technology, such as the
Mikoyan-Gurevich MiG-25, the process may be secret. For others,
including consumer electronics, the results are typically disseminated
through photographs and component lists so that others can make use of
the information without having to disassemble the product themselves.
Best Answer
This term was originally from electronic components and defined the flow between their inputs and outputs. Fan-in refers to the number of higher-level modules that directly call the module, while fan-out refers to the number of lower-level modules directly called by the module.
This refers to the shard being ingested (called) by a number of consumers (lower-level modules). The shard in Kinesis has a limited outbound throughput (2MB/second), it is shared by very limited clients. And this feature enables to achieve higher outbound throughput without having to provision more streams or shards in the same stream, so each consumer has that 2MB/s throughput.
Sometimes larger requests may take longer to complete than smaller request. So it's worth testing whether the request handling can speed up if we turn one large request into a number of smaller requests instead. So here fan-out means split a large request payload into smaller batches and send out the request multiple times (lower-level modules) to the service.
One use case I can think of is fan-out write/read.
For example, if you tweet and Twitter delivers that to all the subscribers feeds as soon as it is written (fan-out write). Or a feed service that waits until users are actually consuming the feed, at that time it looks for posts that have been written that this user is eligible to read (fan-out read).