f you’ve used Go for a while you’re probably aware of some of the basic Go concurrency primitives:
gokeyword for spawning goroutines
- Channels, for communicating between goroutines
contextpackage for propagating cancellation
sync/atomicpackages for lower-level primitives such as mutexes and atomic memory access
These language features and packages combine to provide a very rich set of tools for building concurrent applications. What you might not have discovered yet is a set of higher-level concurrency primitives available in the “extended standard library” available at golang.org/x/sync. We’ll be taking a look at these in this article.
This article is based on Go 1.13.
Go provides us a tool to enable tracing during the runtime and get a detailed view of the execution of our program. This tool can be enabled by flag
-trace with the tests, from
pprof to get live tracing, or anywhere in our code thanks to the
trace package. This tool can be even more powerful since you can enhance it with your own traces. Let’s review how it works.
Yet data modeling with DynamoDB is tricky for those used to the relational databases that have dominated for the past few decades. There are a number of quirks around data modeling with DynamoDB, but the biggest one is the recommendation from AWS to use a single table for all of your records.
In this post, we’ll do a deep dive on the concepts behind single-table design. You’ll learn:
- What is single-table design
- Why single-table design is needed
- The downsides of single-table design
- The two times where the downsides of single-table design outweigh the benefits