Sara has been running the same report for eighteen months. She opens her SQL client mid-morning, launches the query for average basket by city and goes off for a coffee, because she knows it takes between four and six minutes. What she did not know until module 5 —until the mercadofresco-produccion dashboard showed it in a chart— is that during those minutes the shop's latency rises, and that the complaints on the Friday she ran it at 18:30 were no coincidence.

The migration to Aurora has improved things: a custom endpoint isolates Sara's queries on aurora-mf-lector-lotes and the shop no longer notices them. But the reports still take exactly as long, because the problem was never one of isolation: it is that a row-oriented engine reads 48 million complete rows of 40 columns in order to use 4, uncompressed and unparallelised. Amazon Redshift is AWS's data warehouse: a columnar, compressed, massively parallel engine designed for precisely the question Sara asks every day. Here the reports leave the transactional database for good, are modelled as a star schema and go from minutes to seconds.

Cost warning. Redshift is one of those services that generate a bill fastest if you are careless: a forgotten provisioned cluster costs hundreds of dollars a month. When you finish any test, delete the namespace and the workgroup.

Compliance warning. An analytical warehouse concentrates the complete purchase history of every customer in one place: in GDPR terms it is MercadoFresco's most sensitive asset. The anonymisation, the legal basis for analytical processing and the retention policy must be documented and reviewed by the data protection officer before the first load.

1. OLAP versus OLTP: why a report kills a transactional database
2. Columnar storage, compression and massively parallel execution
3. Architecture: leader node, compute nodes and slices
4. RA3, DC2 and Redshift Serverless
5. MercadoFresco's star schema
6. Distribution and sort keys
7. Loading data with COPY and the nightly pipeline
8. Zero-ETL integration from Aurora
9. Redshift Spectrum, Athena and AWS Glue
10. Sara's business queries
11. Materialised views
12. Concurrency, WLM queues and concurrency scaling
13. Security, permissions and anonymisation
14. Costs, pause and resume
15. Common mistakes and tips
16. Exercises
17. Conclusion

In 06-01 we saw the table that separates the two worlds. Now it is time to see the concrete mechanism, with Sara's real query:

The pedidos table has 40 columns and 48 million rows, with an average row size of 380 bytes. The query needs three: id_cliente, importe and fecha_pedido, about 28 bytes.

In a row-oriented engine the data is stored one complete row after another. To read 28 bytes you have to read all 380, because disk is read in blocks and every block holds whole rows:

The reduction is no trick: it is reading 48 times less data and spreading it over dozens of processes.

Storing by columns has a second advantage that multiplies the first: every value in a block is of the same type and very similar to its neighbours, so it compresses extraordinarily well.

Redshift chooses the encoding by itself: with ENCODE AUTO —the default behaviour— it analyses the data as it is loaded and applies whatever fits. The practical recommendation is to leave it on automatic unless you have a measured reason to do otherwise; ANALYZE COMPRESSION shows what it would recommend on data that is already loaded.

The third piece is MPP (massively parallel processing): the table does not live in one place, it is spread across every node and each one processes its share simultaneously. With 4 nodes of 4 slices, Sara's query splits into 16 jobs that each read and aggregate 3 million rows at once, and the partial results are combined at the end. Hence the difference between minutes and seconds.

This also explains why Redshift is bad at the opposite: retrieving one specific order by its identifier means coordinating every node to return a single row. Aurora does it in 2 ms with an index; Redshift takes hundreds of milliseconds. Redshift does not replace Aurora: it complements it.

The leader node receives the query, parses it, generates the plan, compiles the code and hands it out; it stores no user data and is the only connection point. The compute nodes run their portion and return partial results. The slices are the divisions within each node, one per vCPU: the real unit of parallelism, and the reason the distribution key matters so much, because if the data is not spread evenly across slices, half the hardware sits idle.

DC2 is the older generation: fast, but with local storage, so growing in data forces you to add nodes you do not need for compute. RA3 separates the two, with managed storage on S3 and an automatic local cache. Redshift Serverless removes the concept of a node altogether: you define a workgroup with a base capacity in RPUs (Redshift Processing Units, minimum 8), you pay per RPU-second while queries are running, and when there is no activity there is no compute charge, only storage.

MercadoFresco's analytical usage profile, as measured:

Four minutes of compute a day out of a possible 1,440: a provisioned cluster would be switched on and doing nothing 99.7 % of the time.

Two orders of magnitude, no argument. A provisioned cluster is justified when there are queries practically all day, dozens of analysts and predictable load: that will be MercadoFresco's situation in a few years' time, not today.

--max-capacity 64 is the spending limit: without it, a badly written query scales and bills for it. And --no-publicly-accessible with private subnets is non-negotiable: the warehouse holds the purchase history of every customer.

In OLTP you normalise to avoid duplication; in OLAP you denormalise into a star: one large fact table with the numeric measures, surrounded by small dimensions holding the descriptive attributes. Fewer joins, and the ones that remain are against small tables.

Two details that come as a surprise if you arrive from PostgreSQL. Redshift does not enforce primary or foreign keys: you can declare them, and it is worth doing because the planner uses them to optimise, but it does not verify them —integrity is guaranteed by the load process—; and there are no indexes, because the sort key plays that role. Dimensions should also have surrogate keys (sk_*, small integers) rather than the source identifiers: they take up less space, compress better and make it possible to keep history when an attribute changes —if a customer moves city, the old orders must go on counting towards the city they were delivered to.

The distribution key decides which slice each row lands on, and it is the decision that affects performance most.

What happens when you choose badly is concrete and measurable. If hechos_pedidos is distributed by sk_producto and the query joins on sk_cliente, Redshift has to redistribute the fact table across the network on every query: that is the DS_DIST_BOTH step in the execution plan, and it can multiply the duration by ten. Worse still is skew: if you distribute by sk_ciudad and 45 % of the orders come from Madrid, that 45 % lands on a single slice and one process works while fifteen wait. It is the hot key from 06-02 under another name.

In MercadoFresco DISTKEY (sk_cliente) is chosen because there are tens of thousands of customers spread reasonably evenly and because the cohort and average basket queries group by customer. And the four dimensions go with DISTSTYLE ALL because they are tiny: replicating them costs little and eliminates all redistribution in the joins. To diagnose skew you compare the number of rows per slice in the system views: if the maximum and the minimum differ a lot, the key is badly chosen.

The sort key determines the physical order of the rows on disk. Redshift stores the minimum and maximum value of every one-megabyte block, so if a query filters on the sort key the engine discards whole blocks without reading them. It is the conceptual equivalent of a clustered index.

SORTKEY (sk_tiempo, sk_ciudad) on hechos_pedidos reflects the fact that every one of Sara's queries filters on a date range: with 18 months of history and a query about the last quarter, Redshift discards 83 % of the blocks before reading anything. The order matters: the first column must be the one most used for range filtering, and putting sk_ciudad first would waste almost all the benefit, because the city filter is an equality one and appears less often.

Three warnings. New loads arrive unsorted and sit in an unsorted region that VACUUM SORT ONLY reorganises; with a date key and incremental loading by date it is hardly ever needed, because the data arrives almost in order already. ANALYZE refreshes the planner's statistics, without which the plan can be dreadful —Serverless runs both by itself, in the background. And interleaved sort keys (INTERLEAVED) give equal weight to several columns, but they only pay off in specific cases and cost a lot in maintenance: the default recommendation is the compound one.

COPY is the only sensible way to load volume into Redshift: it reads from S3 in parallel from every slice at once. A row-by-row INSERT is between a hundred and a thousand times slower.

Four decisions lie behind those four lines. Parquet, not CSV: it is columnar and compressed at source, so the load is faster, there is no schema to declare and the types come defined —there is no ambiguity between 12,40 and 12.40. A prefix, not a file: COPY loads every object under the prefix in parallel, and the rule of thumb is to generate a multiple of the number of slices in files of 1 to 128 MB compressed, because a single giant file leaves every slice but one idle. IAM_ROLE, never access keys in the SQL: the role is assumed by the cluster and audited by trail-mercadofresco. And a manifest when exactness is required —a JSON that explicitly lists the objects with "mandatory": true—, which is what guarantees that the nightly load processes exactly the files the export generated, not one more and not one less.

After every load it is worth reviewing STL_LOAD_ERRORS, which explains row by row what failed. It is the first table to look at when a COPY complains.

Four rules make it reliable. Incremental, not full: only orders with a fecha_modificacion later than the last watermark are exported, not all 48 million every night. Idempotent: if the process is retried the result must be the same, and that is achieved by deleting the day's partition before loading it, inside a transaction. From the replica, never from the writer: that is exactly what aurora-mf-lector-lotes exists for. And with an alarm, because a silent failure means Sara looks at stale data without knowing it, which is worse than having no report at all.

Orchestrating these steps —with retries, dependencies and failure handling— is the job of Step Functions and EventBridge, covered in 07-03 and 07-04. Here it is enough to know that the pipeline exists and what guarantees it has to meet.

Zero-ETL integration continuously replicates Aurora PostgreSQL tables to Redshift, with a lag of seconds and without writing a single line of pipeline. You configure an integration between the source cluster and the destination namespace, and AWS maintains the copy.

They are not mutually exclusive, and the combination is what MercadoFresco ends up using: zero-ETL integration brings the normalised tables over in near real time and a process inside Redshift transforms them into the star schema. You gain freshness and remove the most fragile part of the pipeline while keeping the optimised model.

Spectrum lets you query data that is sitting in S3 without loading it, through external tables defined in the AWS Glue data catalogue.

MercadoFresco's case: keep the last 24 months in Redshift and leave in S3, in infrequent access classes (02-03), everything older plus the abandoned baskets we exported in 06-02. Billing is by TB scanned, so partitioning by date and using Parquet is what separates a query costing pennies from one costing tens of dollars.

Athena (05-03, where we queried trail-mercadofresco) also runs SQL over S3. The honest question is when it is enough.

Athena is enough for occasional exploration, log analysis and any case of a few queries a month. Redshift is needed when the same queries repeat daily, when there are dashboards that refresh by themselves, when there are joins between several large tables, or when repeated scanning in Athena starts costing more than the warehouse. For MercadoFresco, with 3-8 daily reports over the same tables and a dimensional model to maintain, Redshift Serverless is the choice; Athena remains the tool for the CloudTrail logs and for one-off exploration over S3.

AWS Glue provides the data catalogue: the central register of which tables exist, where they are and what schema they have. Athena, Spectrum and Glue jobs all share it, so defining a table once makes it visible from all three, and the crawlers can deduce the schema by walking through a prefix in S3.

This is the query that lets Marta decide how much fresh produce to order from the market on Thursday night: not the best seller overall, but the one that spikes specifically on Friday.

All three took minutes on Aurora and take seconds on Redshift. And all three are impossible in DynamoDB: this is the "exploratory queries" criterion from 06-01 turned into SQL.

A materialised view stores the pre-computed result of a query. Redshift can refresh it incrementally, processing only the new data, and it automatically rewrites queries so that they use the view even when the user does not mention it.

The business dashboard goes from aggregating 48 million rows to reading a few thousand. AUTO REFRESH YES lets Redshift decide when to refresh according to activity; with a nightly pipeline an explicit REFRESH MATERIALIZED VIEW at the end of the load works just as well, and gives exact control over when the numbers Sara sees change.

Workload management (WLM) organises queries into queues with their own memory and priority, so that one heavy report does not block the rest. Manual WLM requires configuring queues, memory and concurrency by hand and does not adapt; automatic WLM only asks for priorities and adjusts itself, and it is the default choice except in very specific cases.

With automatic WLM you define priorities per user group: dashboards on HIGHEST because they are fast and many eyes are on them, Sara's exploratory queries on NORMAL, and the nightly load on LOW because nobody minds if it takes ten minutes longer in the middle of the night.

Two complementary mechanisms: concurrency scaling, which adds temporary capacity when a queue builds up —in Serverless it is built into RPU scaling—, and query monitoring rules (QMR), which automatically abort anything that runs away (for example, any query that exceeds 15 minutes or scans more than 500 GB). It is the most effective way of stopping an accidental SELECT * from eating the budget.

Network. The workgroup lives in the private subnets snet-mercadofresco-datos-a and -b, with sg-mercadofresco-basedatos and no public access; Sara connects through the console's query editor v2, which requires nothing to be opened. Encryption at rest with alias/mercadofresco-datos and in transit with mandatory TLS. And read-only permissions for the mercadofresco-analitica group:

ALTER DEFAULT PRIVILEGES is the line people forget: without it, the tables created tomorrow will not be readable and somebody will end up granting excessive permissions to get past the problem.

Anonymisation and GDPR. The warehouse must not contain name, postal address, telephone number, email or identity document. No business question needs them: the average basket by city needs the city, not the street. The pipeline replaces the customer identifier with a surrogate key that has no reversible mapping outside a controlled store, aggregates the address to city or postcode level, and discards the rest. Beyond that, data analysis is a different purpose from managing the order and needs its own legal basis, its mention in the privacy policy and a documented retention policy. Redshift offers row-level access control and dynamic column masking for cases where some sensitive item has to remain. All of this design must be reviewed by the data protection officer before the first load: it is far cheaper than redesigning the warehouse afterwards.

With Serverless, the "pause" is automatic: with no queries there are no RPUs and no compute charge. Even so it is worth setting a usage limit that warns or cuts off above a monthly threshold:

On provisioned clusters, pause-cluster and resume-cluster stop the compute charge while keeping the data, and they can be scheduled: it is the lever that turns a 1,500 USD/month development environment into a 300 USD one.

Cleanup. When you finish any test: delete the workgroup and the namespace —with a final snapshot if the data matters—, drop the external Glue tables and review whatever objects you have left in mercadofresco-informes-analitica. Check in Cost Explorer that the Componente=analitica tag goes back to zero the following month.

Using Redshift as a transactional database. This is the serious conceptual mistake. Redshift has no indexes for point lookups, and row-by-row INSERT statements are painfully slow. Load in batches with COPY and query in aggregate; transactional work stays in Aurora.

Loading with INSERT. Between a hundred and a thousand times slower than COPY, and it also fragments the table. If the data arrives one row at a time, accumulate it in S3 and load in batches.

Choosing the distribution key by intuition. Distributing by a column with few distinct values produces skew and wastes the parallelism. Distributing by a column other than the one used in the joins produces redistribution on every query. When in doubt, AUTO, and check afterwards with EXPLAIN looking for DS_DIST_BOTH.

Putting a column you never filter on into the sort key. It contributes nothing. The first column must be the one you filter on by range, which is almost always the date.

Forgetting ANALYZE and VACUUM on provisioned clusters. Without statistics the planner makes bad decisions and without VACUUM the table degrades. Serverless runs them itself, but know they exist.

Loading personal data without anonymising it "so as not to lose detail". You end up with the company's most sensitive asset replicated in a system more people have access to, with no clear legal basis. Anonymisation is designed before the first load.

A single enormous file in the COPY. It leaves every slice but one idle. Split into a multiple of the number of slices, in chunks of 1 to 128 MB compressed.

Leaving a provisioned cluster switched on "to try things out". It is the most expensive slip in this module: 1,500 USD a month for a cluster nobody uses. Serverless, or a scheduled pause.

Tip: measure the before and the after. Record how long Sara's three reports take on Aurora and compare with Redshift. It is the number that justifies the project to management, and you get it free in SVL_QUERY_METRICS and in the module 5 dashboards.

Tip: start small and with Spectrum. Before designing the complete star schema, export to Parquet and query with Spectrum or Athena. If that is enough, you have saved yourself a warehouse. Complexity is added once it has been shown to be necessary.

MercadoFresco adds the hechos_reparto fact table, with one row per delivery: 12 million rows, columns sk_tiempo, sk_ciudad, sk_repartidor (40 distinct values), sk_pedido, minutos_entrega, km_recorridos and incidencia (boolean, true in 3 % of cases). The usual queries are: average delay by city and month; incidents per driver over the last week; and a cross-reference with hechos_pedidos on sk_pedido to relate delay to order value.

Decide the DISTSTYLE, DISTKEY and SORTKEY, justify each choice, and state what would happen if it were distributed by sk_repartidor and which signal in the execution plan would give it away.

A sister company of MercadoFresco, selling catering equipment, has 40 GB of order history in S3 in CSV format. Its analyst runs between three and five queries a month, always exploratory and always different from one another, and there are no dashboards. It is considering setting up Redshift Serverless "because that is what the big players do".

Answer: (a) what do you recommend and why, with numbers; (b) which two changes to the data would make its option much cheaper and faster without changing service; (c) which three concrete signals would indicate, a year from now, that the time has come to move to Redshift.

Write the design of the nightly pipeline that carries the day's orders from aurora-mercadofresco-pedidos to hechos_pedidos. It must cover: which endpoint it reads from and why; how only new or modified records are selected; format, partitioning and file size in S3; how idempotence is guaranteed if the process is retried; how dimensions are loaded when an attribute changes (for example, a customer who moves city); what is done with personal data; and how a failure is detected and notified. Also state which part of this design would disappear if zero-ETL integration were used.

Solution 1

DISTSTYLE KEY with DISTKEY (sk_pedido) and SORTKEY (sk_tiempo, sk_ciudad).

Distribution: the most expensive of the three queries is the cross-reference with hechos_pedidos, which is the large table. If both tables are distributed by the same column —sk_pedido— the rows that have to be joined are on the same slice and the join resolves locally, without moving anything across the network. That is the co-location pattern, and it is the main reason for choosing KEY. sk_pedido also has high cardinality and an even spread, so there is no skew. Note: hechos_pedidos is distributed by sk_cliente, so to exploit co-location fully you would have to consider unifying the criterion or accepting redistribution of the smaller table, which with 12 million rows is bearable; the decision is taken by measuring with EXPLAIN.

Sorting: the first two queries filter on a time range ("by month", "the last week"), so sk_tiempo has to come first so that blocks can be discarded. sk_ciudad in second position helps the first report.

If it were distributed by sk_repartidor: with 40 distinct values and a 16-slice cluster, at most 16 slices would receive data and very unevenly at that —drivers in Madrid have far more deliveries. The result is severe skew: a few slices with millions of rows and the rest almost empty, with the parallelism wasted. The signal in the execution plan would be DS_DIST_BOTH or DS_BCAST_INNER in the join with hechos_pedidos, and in the system views you would see an enormous difference between the slice with the most rows and the one with the fewest. The general rule: never distribute by a low-cardinality column.

Solution 2

(a) Athena, without a doubt. With 40 GB and five queries a month, even if each one scanned the whole history that would be 0.04 TB × 5 × 5 USD = 1 USD a month. Redshift Serverless would cost storage plus the compute of each session, plus designing and maintaining a dimensional model nobody is going to exploit. And the deciding characteristic: the queries are always different and exploratory, so there is nothing to pre-compute and no materialised view to amortise. All of Redshift's value —optimised model, views, concurrency— rests on repetition, and here there is none.

(b) Two changes: convert to Parquet and partition by date. Parquet with compression reduces 40 GB to some 6-8 GB and, being columnar, a query that uses 4 columns out of 30 scans a fraction of that. Partitioning by year and month in the S3 prefix lets Athena discard whole partitions when the query filters by date. Combined, it is common to go from tens of gigabytes scanned to hundreds of megabytes: the bill drops to pennies and the query from a minute to a few seconds. Both changes are an afternoon's Glue work and do not change service.

(c) Three signals for moving to Redshift. First, repetition: dashboards or recurring daily reports appear, and at that point materialised views and the dimensional model start to pay for themselves. Second, concurrency: they go from one analyst to a team with simultaneous queries and begin to hit Athena's quotas. Third, crossed cost: the monthly Athena bill approaches the cost of a Serverless workgroup —15-20 USD a month with this profile—, the point at which Redshift gives more for the same money. A fourth, qualitative sign: when queries start joining three or more large tables, Athena degrades a long way before Redshift does.

Solution 3

Source and endpoint. It reads from the custom endpoint that points to aurora-mf-lector-lotes, the isolated replica from 06-03. Never from the writer —the export competes with the orders— and never from the general reader endpoint, because it would fill the cache of the replica that serves customers their history with pages 18 months old.

Incremental selection. A watermark in Parameter Store (/mercadofresco/produccion/analitica/marca-agua) with the last fecha_modificacion processed. The query selects WHERE fecha_modificacion > :marca AND fecha_modificacion <= :corte, with :corte fixed at the start of the process so that writes occurring during the export are left for the following night and are neither lost nor duplicated. It requires fecha_modificacion to be indexed and maintained by a trigger.

Format in S3. Parquet with Snappy compression, in s3://mercadofresco-informes-analitica/hechos/pedidos/anio=2026/mes=08/dia=02/, with files of 64-128 MB in a number that is a multiple of the parallelism. Partitioning by date in the prefix is what makes Spectrum queries cheap and allows a specific day to be reprocessed.

Idempotence. Inside a transaction: DELETE FROM hechos_pedidos WHERE sk_tiempo = :dia; followed by the COPY of the partition, with a manifest that explicitly enumerates the files and "mandatory": true. If the process is retried, the result is identical. The manifest also prevents partial files from an aborted run being loaded.

Changing dimensions. A type 2 slowly changing dimension is applied: when a customer moves city, their row is not updated; the current one is closed (fecha_fin, es_actual = false) and a new one is inserted with a different surrogate key. That way old orders keep pointing at the row that was current when they were delivered and the history by city does not rewrite itself. If it were overwritten (type 1), last year's revenue for Valencia would change because a customer moved to Bilbao, which is exactly the kind of error that destroys trust in a data warehouse.

Personal data. Name, address, telephone and email do not leave Aurora. The export projects only the necessary columns, replaces id_cliente with the surrogate key sk_cliente and aggregates the address to city and postcode. The mapping between sk_cliente and id_cliente lives in Aurora, with restricted access, not in the warehouse.

Failure detection. Every run publishes a custom metric MercadoFresco/Analitica/CargaCorrecta (1 or 0) and FilasCargadas in the MercadoFresco/Tienda namespace. Two alarms towards alertas-mercadofresco: one if there has been no successful load before 06:00 —the dangerous case is silence, not error— and another if FilasCargadas deviates more than 50 % from the average of the last 7 days, which detects a truncated export. Load errors are looked up in STL_LOAD_ERRORS.

What disappears with zero-ETL integration. The whole extraction and landing: incremental query, watermark, Parquet, partitioning, manifest and COPY; AWS keeps the tables replicated within seconds. What does not disappear is the transformation into the star schema, the type 2 dimension logic, the anonymisation —critical: replication brings the tables as they are, personal data included, so the projection and the masking have to be done inside Redshift with views and permissions— and watching freshness. The fragile half is simplified, not all of it.

Sara's reports have left the transactional database. You understand why they had to leave: a query that aggregates 18 months reads 18.2 GB on a row-oriented engine in order to use 1.34 GB of useful data, uncompressed and with a single process, whereas columnar storage reads only the columns it needs, compresses them 3 to 4 times because neighbouring values look alike, and processes them in parallel across every slice at once. From 4-6 minutes to 2-6 seconds, and with the symmetry worth remembering: Redshift is equally bad at returning one specific order by its identifier. It does not replace Aurora, it complements it.

You know the architecture —leader node that plans and combines, compute nodes, slices as the real unit of parallelism—, the difference between DC2, RA3 and Serverless, and the arithmetic that decides it for MercadoFresco: four minutes of compute a day means a provisioned cluster would be switched on 99.7 % of the time doing nothing, 1,586 USD against 14 USD a month. With mercadofresco-analitica as the namespace, wg-mercadofresco-analitica as the workgroup in private subnets, and --max-capacity as a real spending limit.

You can design the analytical schema: the star schema with hechos_pedidos and the dimensions dim_producto, dim_cliente, dim_tiempo and dim_ciudad, with surrogate keys and without trusting foreign keys that Redshift declares but does not verify. And above all you can choose the two keys that decide performance: the distribution key, with KEY to co-locate the large tables that are joined, ALL for small dimensions and the warning that a low-cardinality column produces skew and leaves half the hardware idle; and the sort key, with the date first, which discards whole blocks thanks to the per-block minimums and maximums.

You can handle loading with COPY from mercadofresco-informes-analitica —Parquet, one prefix with many files of 1 to 128 MB, IAM_ROLE instead of keys, a manifest with mandatory when exactness matters— and the nightly pipeline: incremental, idempotent, from the replica and with an alarm, because the dangerous failure is the silent one. You know zero-ETL integration from Aurora and when to combine it with your own transformation; Spectrum for querying S3 without loading; and the honest comparison with Athena, which is enough when queries are sporadic and different, with Glue as the shared catalogue. Plus materialised views, automatic WLM with priorities per group and the rules that abort the runaway query.

And you know that this is the company's most sensitive asset: private subnets, encryption with alias/mercadofresco-datos, read-only access for the mercadofresco-analitica group with ALTER DEFAULT PRIVILEGES so that tomorrow's tables are covered too, and anonymisation designed before the first load —no business question needs the customer's street— with review by the data protection officer. For around 16 USD a month, with a usage limit configured and the instruction to clean up whatever you create to practise.

One workload remains of the four we diagnosed in 06-01, and it is the most absurd of them all. The catalogue is queried 4,100 times a minute at peak hour in order to return, 94 % of the time, exactly what it returned the time before: prices and descriptions that change once a day, at 06:00, when the delivery from the market arrives. Aurora resolves each of those queries correctly in a few milliseconds, but doing it 4,100 times a minute in order to contribute no new information at all is wasted work paid for in latency, in capacity and on the bill. In 06-05, "Amazon ElastiCache", the catalogue will be served from memory in microseconds: we will look at Redis versus Memcached, the caching patterns with their code, the data structures applied to the Friday ranking and the fast basket, the sessions that will finally make the shop truly stateless, and the close of the module with MercadoFresco's complete data layer.