postgresql GROUP BY and latest date filter by non group by statement?
The WHERE clause goes before the GROUP BY:

SELECT 
    other_key, 
    SUM(quantity) AS sum_quantity,
    MAX(date)     AS max_date 
FROM demo 
WHERE key = ?
GROUP BY other_key 
ORDER BY max_date ; 


By the way key is a reserved keyword in SQL - although it isn't in Postgres. It would be best to be avoided as a column or table name. 

For the additional question, to also calculate the cumulative sums (order by date) and then find the (oldest) date that these sums went positive and stayed positive, it's easier done with some window functions:

SELECT 
    other_key,  
    total_sum_quantity, max_date,
    CASE WHEN cumulative_sum &gt; 0 THEN cumulative_sum END AS cumulative_sum,
    CASE WHEN cumulative_sum &gt; 0 THEN date END AS oldest_positive_strike_date
FROM
  ( SELECT 
        *,
        ROW_NUMBER()
            OVER (PARTITION BY other_key
                  ORDER BY date DESC)  AS rn   
    FROM 
      ( SELECT 
            other_key, quantity, date,
            SUM(quantity) OVER (PARTITION BY key, other_key) AS total_sum_quantity,
            MAX(date) OVER (PARTITION BY key, other_key)     AS max_date,
            SUM(quantity) OVER (PARTITION BY key, other_key
                                ORDER BY date)               AS cumulative_sum,
            LAG(quantity) OVER (PARTITION BY key, other_key
                                ORDER BY date)               AS prev_quantity
        FROM demo 
        WHERE key = '0A19882'
      ) AS t
    WHERE (cumulative_sum  &gt; 0 AND cumulative_sum-quantity &lt;= 0)
       OR (cumulative_sum &lt;= 0 AND cumulative_sum-quantity  &gt; 0)
       OR (prev_quantity IS NULL)
  ) AS t2
WHERE rn = 1 ;


Test at rextester.com.

Some notes:


The cumulative_sum returned is the cumulative sum at the point of the oldest_positive_strike_date. If the total cumulative sum is not positive, both these columns will show NULL.
The PARTITION BY key, other_key can be replaced by PARTITION BY other_key. I left as it is, in case you need to run the query not just with one key value but with more, eg. for the whole table or with WHERE key IN (...).
The ORDER BY date will be deterministic if the (key, other_key, date) has a UNIQUE constraint/index. If there is a chance that you have two rows with same key, other_key and date, replace that with something that can identify a row, eg. ORDER BY date, id.
The "obvious" index that will benefit the query would be on (key, other_key, date, quantity). Postgres may choose a different plan though, scanning the table or using the index and also checking the values against the table. this depends on various factors. Experiment with various table sizes and with the work load you expect.
Since the initial WHERE key = ? condition will restrict the rows to about 100 (from a 100K table), it might be more efficient to use a CTE that gets these rows first, using something like the following. You may get away with a simple index on (key) and have good performance:

WITH a AS
  ( SELECT * 
    FROM demo
    WHERE key = ?
  ) 
SELECT ... ;          --- the query as it is, without the `WHERE`