Fix broken link (#3575)

site/content/architecture/m3db/engine.md

@@ -80,7 +80,7 @@ In addition, with large volumes of data, it becomes prohibitively expensive to k
 M3DB takes a two-pronged approach to persistent storage that involves combining a [commit log](/docs/architecture/m3db/commitlogs) for disaster recovery with periodic flushing (writing [fileset files](/docs/architecture/m3db/storage) to disk) for efficient retrieval:
 
 1.  All writes are persisted to a commit log (the commit log can be configured to fsync every write, or optionally batch writes together which is much faster but leaves open the possibility of small amounts of data loss in the case of a catastrophic failure). The commit log is completely uncompressed and exists only to recover unflushed data in the case of a database shutdown (intentional or not) and is never used to satisfy a read request.
-2.  Periodically (based on the configured block size), all data in the buffer is flushed to disk as immutable [fileset files](/docs/architecture/m3db/storage). These files are highly compressed and can be indexed into via their complementary index files. Check out the [flushing section](#flushing) to learn more about the background flushing process.
+2.  Periodically (based on the configured block size), all data in the buffer is flushed to disk as immutable [fileset files](/docs/architecture/m3db/storage). These files are highly compressed and can be indexed into via their complementary index files. Check out the [flushing section](/docs/architecture/m3db/engine#flushing) to learn more about the background flushing process.
 
 The block size parameter is the most important variable that needs to be tuned for a particular workload. A small block size will mean more frequent flushing and a smaller memory footprint for the data that is being actively compressed, but it will also reduce the compression ratio and data will take up more space on disk.