Microservices and antibody staining
As a software engineer exploring biology, it is always a delight to come across techniques in biology research that echo design principles from software. Here is an illustrative example that reminded me of microservices, and in particular, the principle of separation of concerns.
Our example comes from immunohistochemistry (IHC), a technique for visualizing cells by staining them with antibodies.
IHC has many applications in academic research and clinical diagnosis. For example, pathologists can use IHC on metastatic tumor samples from cancer patient to identify the body tissue the tumor originated from.
IHC uses antibodies that bind to a specific protein. These antibodies are conjugated with an additional molecule that allows the researcher to visualize the antibodies.
To illustrate the process, let’s return to the previous example with the metastatic tumor. Let’s say you are a pathologist looking at a metastatic tumor and trying to figure out where it originated from. You take the tumor sample and apply IHC using antibodies that bind to proteins that are only expressed in prostate cells. These antibodies are conjugated with a fluorescent tag. After the antibodies given time to bind and the remainder is washed away, you shine the appropriate wavelength of light on the tumor sample and see if anything fluoresces. Since the antibodies only bind to proteins found in prostate cells, this allows you to determine if the tumor sample originally came from the prostate.
Now that we have some sense of how IHC works, let’s talk about primary and secondary antibodies.
In IHC, there are two concerns you need your antibody system to fulfill:
- Bind to a different target proteins (i.e. antigens)
- Make yourself visible to the human eye.
For both concerns, there are a lot of cases to cover.
For (1), there are hundreds of thousands of different proteins in the body that you may want to bind to.
For (2), there are multiple ways to make the antibodies visible (another example is chromogenic IHC). Even if we restrict ourselves to fluorescence, scientists often want to stain multiple proteins in the same experiment, which means they will want different antibodies to react to different wavelengths of light.
If you tried to satisfy both concerns with a single antibody molecule, there would be a combinatorial explosion of distinct molecules required. Furthermore, there is a risk that the concerns will interfere with each other. Attaching a large fluorescent protein (concern 2) may cause certain antibodies to lose their ability to bind to their target protein (concern 1), perhaps because the fluorescent protein gets in the way of the binding site.
To solve these issues, life scientists have applied what software engineers would recognize as the principle of separation of concerns. They’ve introduced a two-antibody system, with primary and secondary antibodies. Primary antibodies just handle binding (concern 1) and secondary antibodies just handle visualization (concern 2). This approach is known as “indirect IHC”.
The secondary antibody no longer has to worry about binding to arbitrary proteins. It only needs to bind to the constant region of the primary antibody. There is a clean well-defined interface between the primary and secondary antibodies, a fact software engineers will appreciate.
This design reduces the cost of commercial antibodies and allows scientists to mix-and-match antibodies for their particular experimental needs.²
A wonderful example of engineering design principles at work in the life sciences!
¹ Note that in the diagram, multiple secondary antibodies are bound to the primary antibody. This is another advantage of the two-antibody design: it allows for the amplification of weak fluorescent signals by recruiting multiple secondary antibodies per protein, allowing scientists to detect lower protein concentrations.
² There are also disadvantages to the two-antibody design, one of them being additional complexity in executing the technique.
